Strictness in data declaration not matched in assembler?
Jan-Willem Maessen
jmaessen at alum.mit.edu
Wed Oct 15 11:21:39 EDT 2008
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
More information about the Glasgow-haskell-users
mailing list