stranal/sigs/UnsatFun

[Richard Eisenberg]

These responses are helpful, thanks.

Is there a primer for how to read the output? Or a small function that produces the output that I could quickly reverse engineer?

There is a suggestion to look at the core before and after my patch. Is there a certain phase I should look at? What should I look for?

And where in the GHC code base should I start looking to understand this better?

Sorry if these questions seem too easy -- I'm just out of my element here. My hunch is that I need to update something in the strictness analyzer to look through/around/beyond coercions somewhere. Any ideas as to what that might be would be helpful! :)

Thanks,
Richard

On Nov 29, 2015, at 2:49 PM, Ben Gamari <ben at smart-cactus.org> wrote:

> Richard Eisenberg <eir at cis.upenn.edu> writes:
> 
>> Hi devs,
>> 
>> On my kind=type branch (D808), I have this test failure for stranal/sigs/UnsatFun:
>> 
> Hmmm. I was curious and so took the opportunity to do a bit of digging.
> This likely isn't helpful but you never know...
> 
>> -UnsatFun.g: <B,1*U(U)>b
>> +UnsatFun.g: <L,U(U)>
> 
> It looks like the strictness analyzer can no longer see that `g` is
> bottoming (hence the missing `b`), which unfortunately seems to be
> exactly what this test is testing for. :(
> 
> Moreover, the `B` changing to an `L` means that the demand analysis
> can't see that any demand is made of the first argument.
> 
>> -UnsatFun.h: <C(S),1*C1(U(U))>
>> +UnsatFun.h: <S,1*U>
> 
> This is the helper used by `g`. Again, it looks like something is going
> awry here with strictness analysis as the argument which was previously
> deemed "call-demand" is now just "strict".
> 
>> -UnsatFun.g': <L,1*U(U)>
>> +UnsatFun.g': <L,U(U)>
>> 
>> -UnsatFun.h2: <S,1*U><L,1*C1(U(U))>
>> +UnsatFun.h2: <S,1*U><L,1*U>
> 
> This appears to be a very similar test which is likely failing for a
> similar reason.
> 
> Could you perhaps collect the Core for this test before and after your
> patch?
>