Strictness in data declaration not matched in assembler?

[Simon Marlow]

Lennart Augustsson wrote:
> True, if there can be indirections then that's bad news.
> That would make strict fields much less efficient.
> But I don't see why indirections should be needed.  Simon?

This kind of thing has always been a problem for GHC, and IIRC hbc does/did 
better here.

I don't know for sure whether we guarantee not to point to an indirection 
from a strict constructur field.  I imagine it wouldn't be hard to arrange, 
but it is another invariant we'd have to maintain throughout the Core->Core 
phases.  The real problem is that strictness is not represented in the type 
system, so we have no way to check that these kind of invariants are being 
respected.

Cheers,
	Simon

> On Wed, Oct 15, 2008 at 4:21 PM, Jan-Willem Maessen
> <jmaessen at alum.mit.edu> wrote:
>> On Oct 15, 2008, at 11:08 AM, Lennart Augustsson wrote:
>>
>>> I totally agree.  Getting the value of the field should just evaluate
>>> x and then use a pointer indirection; there should be no conditional
>>> jumps involved in getting the value.
>>> GHC is just doing the wrong thing.
>> Can indirection nodes occur in this context?  [I'd think not, but it depends
>> on what pointer we're storing when we force the thunk in the constructor.]
>>  I could see the need for the test if indirection handling is required.
>>
>> -Jan
>>
>>>  -- Lennart
>>>
>>> On Wed, Oct 15, 2008 at 3:58 PM, Tyson Whitehead <twhitehead at gmail.com>
>>> wrote:
>>>> On Wednesday 15 October 2008 10:48:26 you wrote:
>>>>> Strictness does not imply unboxing.
>>>>>
>>>>> To see why not, think about the fact that unboxing breaks sharing. By
>>>>> keeping the pointer-indirection in place, we can share even strict
>>>>> fields between related values.
>>>> I believe I realize that.  What I was wondering about was the fact that
>>>> it
>>>> seemed to think the pointer might be to a thunk (instead of constructor
>>>> closure).  Doesn't the strictness flag mean the following assembler would
>>>> work
>>>>
>>>> sni_info:
>>>>      movq 7(%rbx),%rbx
>>>>      movq $snj_info,(%rbp)
>>>>      jmp snj_info
>>>>
>>>> (which could be cleaned up further by combining it with snj_info) instead
>>>> of
>>>>
>>>> sni_info:
>>>>      movq 7(%rbx),%rbx
>>>>      movq $snj_info,(%rbp)
>>>>      testq $7,%rbx
>>>>      jne snj_info
>>>>      jmp *(%rbx)
>>>>
>>>> (i.e., the whole test if it is a thunk and conditionally evaluate it bit
>>>> is
>>>> unnecessary due to constructor the strictness flag).
>>>>
>>>> Cheers!  -Tyson
>>>> _______________________________________________
>>>> Glasgow-haskell-users mailing list
>>>> Glasgow-haskell-users at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>>
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users at haskell.org
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users