| 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.

You're right.  As Simon says, GHC's Core language has no type distinction 
between an Int that is evaluated and an Int that might be a thunk, so we 
generate conservative code.

However, even for strict functions we do not *guarantee* to pass evaluated 
arguments.  Consider
        f x y = if y==0 then g x else 0
        g x = x+1

Here g is strict, but f is not (in x).  The code that GHC generates for 'f' 
simply passes 'x' along to 'g'.  It does not evaluate 'x' and then pass it.  So 
the fact that 'g' is strict is used to *allow* the caller to use call by value; 
it does not *require* the caller to do so.  So that means that 'g' cannot rely 
on getting an evaluated argument. One could change that, but that's the way it 
is right now.

For strict *constructors*, on the other hand, we *do* guarantee to evaluate the 
argument before building the constructor.  We generate a wrapper thus
        wC = \ab. case a of { a' -> C a' b }
(Remember 'case' always evaluates in Core.)  So for strict constructors we 
could take advantage of the known evaluated-ness of the result to avoid the 
test.

BUT people who care probably UNPACK their strict fields too, which is even 
better.  The time you can't do that is for sum types
        data T = MkT ![Int]

Whether this case is important enough to be worth the complexity cost, I'm not 
sure.


If someone felt like creating a ticket for this thread, and pasting in the 
payload of the messages, that'd help us not to forget it.  As of now, it 
doesn't look like a terribly big win to me.  But I could be wrong -- intuition 
is not always a good guide.

Simon

| -----Original Message-----
| From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Lennart Augustsson
| Sent: 15 October 2008 16:09
| To: Tyson Whitehead
| Cc: GHC users
| Subject: Re: Strictness in data declaration not matched in assembler?
|
| 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.
|
|   -- 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

Reply via email to