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