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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> >> 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@haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users