Strictness in data declaration not matched in assembler?

[Lennart Augustsson]

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?

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
>