[MLton-devel] cvs commit: card maps and machine IL semantics change

[Matthew Fluet]

> Hmm.  The reason that I made the change is that I wanted to avoid
> computing the address twice, once for the cardmap and once for the
> offset.  Maybe that's a stupid reason.  

It depends.  Looking at the gcc produced assembly, it's not doing the CSE
optimization that I think you were hoping it would do:

	RI(0) = Word32_rshift((word)(XP(SP(12), SI(20))), 0x8);
	OC(XC(gcState.heap.cardMap, RI(0)), 0) = '\001';
	OP(XP(SP(12), SI(20)), 0) = RP(2);

                                      # %esi = RP(2)
	movl	20(%edi), %ecx        # %ecx = SP(20)
	movl	12(%edi), %eax        # %eax = SP(12)
	movl	gcState+68, %edx      # %edx = gcState.heap.cardMap
	leal	(%eax,%ecx,4), %eax   # %eax = XP(SP(12), SI(20))
	shrl	$8, %eax              # %eax = RI(0)
	movb	$1, (%eax,%edx)       # OC(XC(cardMap, RI(0)), 0) = '\001'
	movl	20(%edi), %edx        # %edx = SP(20)
	movl	12(%edi), %eax        # %eax = SP(12)
	movl	%esi, (%eax,%edx,4)   # OP(XP(12), SI(20), 0) = RP(2)

So, the address XP(SP(12), SI(20)) is computed twice.

Here's what I would prefer to see, and what I'd hope the codegen would
produce.
        RP(0) = CXP(SP(12), SI(20))
        RI(0) = Word32_rshift((word)RP(0), 0x8)
        OC(XC(gcState.heap.cardMap, RI(0)), 0) = '\001'
        OP(RP(0), 0) = RP(2)

                                      # %esi = RP(2)
        movl    20(%edi), %ecx        # %ecx = SP(20)
        movl    12(%edi), %eax        # %eax = SP(12)
        movl    gcState+68, %edx      # %edx = gcState.heap.cardMap
        leal    (%eax,%ecx,4), %eax   # %eax = RP(0)
        movl    %eax, %ebx            
        shrl    $8, %ebx              # %ebx = RI(0)
        movb    $1, (%ebx,%edx)       # OC(XC(cardMap, RI(0)), 0) = '\001'
        movl    %esi, (%eax)          # OP(RP(0), 0) = RP(2) 

> I could leave ArrayOffset as it was and duplicate the address
> computation, which is only going to happen for pointer stores.  Maybe
> that's not too bad.  We could do benchmarks with that approach and if
> it's good enough, stick with it.
>
> Another way I could go would be to get rid of ArrayOffset altogether
> and explicitly do the address computation in RSSA.  But I can only
> guess that this will suffer from your other point:

No, I don't think getting rid of ArrayOffset altogether is the right thing
to do.  Like I said before, I like to think of ArrayOffset as a location;
when it's just used once, we don't do an explicit address computation, we
just produce an assembly address operand, like (%eax, $ecx, 4).  We'd burn
a lot of code and cycles if we computed 
RP(0) = SP(12) + 4 * (SI(20))
...OP(RP(0), 0) ...
for every use of ArrayOffset.
But, when we need to the address as a value, then it really should be
dropped into a variable.



-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel