GREG modifying the FIXED_REGISTERS...

GREG modifying the FIXED_REGISTERS...

[Jean Christophe Beyler]

Dear all,

I actually have determined that doing what I say below is a bad idea
since it will probably lessen the impact of future optimizations in
the compiler. However, I'm curious to know why it didn't work :-)

Here goes: I've been working on getting better code generation and one
thing I noticed was that it is best to use the register r0 on my
architecture than the constant 0. Therefore, as I expand move
instructions, I check to see I can transform the second operand into
r0 like so:

    /* If we have a 0, use r0 instead */
    if ( ((GET_CODE (op1) == CONST_INT) && (INTVAL (op1) == 0)) ||
                    (GET_CODE (op1) == CONST_DOUBLE &&
CONST_DOUBLE_LOW (op1) == CONST_DOUBLE_HIGH (op1) &&
                        CONST_DOUBLE_LOW (op1) == 0))
    {
            op1 = gen_rtx_REG (GET_MODE (op0),0);
            emit_move_insn (op0, op1);
            return 1;
    }

Now this seems to work correctly and I get the following RTL later
down the line:

(insn:HI 66 64 69 2 strlen.c:37 (set (reg:DI 138)
        (eq:DI (reg:DI 136)
            (reg/f:DI 0 r0))) 80 {*cyclops.md:2813}
(expr_list:REG_DEAD (reg:DI 136)
        (nil)))

However, for a reason that I ignore, the GREG pass, transforms the r0
into r3 which is not at all the same thing:

(insn:HI 66 64 69 2 strlen.c:37 (set (reg:DI 6 r6 [138])
        (eq:DI (reg:DI 6 r6 [136])
            (reg/f:DI 3 r3))) 80 {*cyclops.md:2813} (nil))

This is the output concerning the instruction from the GREG pass:

insn = 66 live = hardregs [62 ] renumbered [6 ] pseudos [  138(6)  135]
  adding def 138(6)
  roc adding 138<=>(6 62 138 135 )
  roc adding 138<=>6
  roc adding 135<=>6
  clearing def 138(6)
  seeing use 0
  seeing use 136(6)
    dying pseudo
  set_renumbers_live 136->6
  starting early clobber conflicts.

Now that I think about it, I believe the problem is that for the GREG,
r0 can be replaced by r3 because I have not told him that r0 is
actually worth 0 all the time though it is defined by the
FIXED_REGISTER macro.

Though I've determined that doing so is actually a really bad idea for
future optimization passes (since this is done in the expand pass). I
would, however, like to understand why the GREG was replacing that
register and not leaving it alone since it was defined as a
FIXED_REGISTER.

What allowed it to change it and why would it change it to r3 that was
also a FIXED_REGISTER.

As always, thanks for any input,
Jean Christophe Beyler

Re: GREG modifying the FIXED_REGISTERS...

[Richard Henderson]

On 08/21/2009 04:01 PM, Jean Christophe Beyler wrote:
>      /* If we have a 0, use r0 instead */

Don't do this.  See how, e.g. alpha and mips handle the zero register.
You want to leave this as (const_int 0) throughout compilation.


r~

Re: GREG modifying the FIXED_REGISTERS...

[Jean Christophe Beyler]

That was also the conclusion I came to. I was now wondering why GREG
allows itself to change that register from r0 to r3. Is there any
reason?

It seems to me that the most likely reason is that it considers in
this case r0 as undefined and thus can modify it to r3 because of
this. I was wondering if this assumption is correct and what "could I
have done" (though I won't) to tell him not to.

This question is now to understand the hows and whys of GREG instead
of how to do what I initially wanted. As I have stated and you have
confirmed, this would be a bad idea. I also noticed that by modifying
my constraints, I'm getting the generated code I was looking for.

Thanks again,
Jc

On Fri, Aug 21, 2009 at 8:12 PM, Richard Henderson<rth@redhat.com> wrote:
> On 08/21/2009 04:01 PM, Jean Christophe Beyler wrote:
>>
>>     /* If we have a 0, use r0 instead */
>
> Don't do this.  See how, e.g. alpha and mips handle the zero register.
> You want to leave this as (const_int 0) throughout compilation.
>
>
> r~
>