x86 optimization and rtx_cost question

Tom Crispin crispin@centtech.com
Fri Jan 11 15:35:00 GMT 2002


Richard Henderson wrote:
> 
> On Fri, Jan 11, 2002 at 11:03:52AM -0600, Tom Crispin wrote:
> >       #define COSTS_N_INSNS(N) ((N) * 4)
> > (why, BTW?  it can't possibly go back to 8080 when "fast" took 4 clocks,
> > or??)
> 
> No, it's just a scaled value.  Otherwise you can't express stuff
> like "Yes, both shift and add take one cycle, but we have two
> adders and one shifter, so prefer that".
> 
> > How can we decide whether to issue ...
> >
> >       movl    var_b, %edx
> >       addl    %edx, %eax
> >
> > ... or ...
> >
> >       addl    var_b, %eax
> 
> Assuming var_b isn't used elsewhere, we should prefer the later form
> until register allocation.  There are peepholes to split this into
> the two insn form based not on cost, but on whether we expect the
> two insn form to schedule better.
> 
> r~

OK.  It makes sense for COSTS_N_INSNS(N) to be scaled, I understood
that.  We much prefer the form

	addl	var_b, %eax

on the VIA C3 since it's a one clock operation.


Moving on - to maybe a better example:


Suppose we compile this function at -O3 -fno-peephole2

	int testf (int a)
	{
	  return a*87;
	}

we get either

        pushl   %ebp
        movl    %esp, %ebp

        imull   $87, 8(%ebp), %eax

        popl    %ebp
        ret

 or
        pushl   %ebp
        movl    %esp, %ebp

        movl    8(%ebp), %ecx
        leal    (%ecx,%ecx,4), %edx
        leal    (%ecx,%edx,2), %eax
        sall    $3, %eax
        subl    %ecx, %eax

	popl	%ebp
        ret



The decision seems to depend on ix86_cost for LEA and MUL on the
particular processor. But is there any code that worries about address
generation interlock?  I haven't seen anything in the main code or in
the peephole optimizations.

And shouldn't the decision about which to use depend on whether or not
we can schedule instructions into the interlock slots?

Am I missing something?

Thanks

BTW - I have subscribed to the mailing list

-- 
Tom Crispin
Centaur Technology
512-493-8625
crispin@centtech.com



More information about the Gcc mailing list