Joern Rennecke writes:
> 2013-05-24 Joern Rennecke
>
> PR rtl-optimization/56833
> * postreload.c (move2add_record_mode): New function.
> (move2add_record_sym_value, move2add_valid_value_p): Likewise.
> (move2add_use_add2_insn): Use move2add_record_sym_value.
> (mo
> Please find attached the updated patch.
Thanks. Still, although reg_mode[regno] is indeed tested above, in
+ for (i = hard_regno_nregs[regno][mode] - 1; i > 0; i--)
+if (reg_mode[i] != BLKmode)
+ return false;
this should be reg_mode[regno + i] instead of reg_mode[i].
And one the n
Please find attached the updated patch.
bootstrapped / regtested for i686-pc-linux-gnu
regtested for i686-pc-linux-gnu X sh-elf
regtested in gcc 4.8 branch for i686-pc-linux-gnu X avr
(--target-board atmega128-sim)
2013-05-24 Joern Rennecke
PR rtl-optimization/56833
* postrel
Quoting Eric Botcazou :
+static bool
+move2add_valid_value_p (int regno, enum machine_mode mode)
[...]
+ for (i = hard_regno_nregs[regno][mode] - 1; i > 0; i--)
+if (reg_mode[i] != BLKmode)
+ return false;
I think that a 'regno' is missing in the second hunk.
Huh? Could you be more
> I've found it is good to have also one mode to invalidate a register for
> all uses; it seems natural to use VOIDmode for that, and then we can use
> BLKmode for all but the first hard register of a multi-hard-reg register.
OK, that sounds sensible.
> I have attached the patch that makes the re
Quoting Joern Rennecke :
Looking into sharing the code with sites that perform essentially the same
function but look somewhat different, I see there's a problem with using
only reg_set_luid to indicate the consistency of a multi-hard-reg-value
in these other contexts.
For values that are use a
Quoting Eric Botcazou :
The patch is OK on principle, but can you factor out the common code? The
endings of move2add_use_add2_insn and move2add_use_add3_insn are identical so
it would be nice to have e.g. a record_reg_value helper function and call it
from there. Similarly, the 3 new checks l
> But I can see that there could be a problem with an earlier value
> that used to be valid in a multi-hard-register sub register to be
> considered to be still valid.
> Setting the mode of every constituent register but the first one
> (which has the new value recorded) to VOIDmode at the same tim
Quoting Eric Botcazou :
The problem was that we had some optimzations added to the
reload_cse_move2add pass that would attempt transformations with
multi-hard-register registers, without keeping track of the validity of the
values in all hard registers involved.
That's not clear to me: for exa
> The problem was that we had some optimzations added to the
> reload_cse_move2add pass that would attempt transformations with
> multi-hard-register registers, without keeping track of the validity of the
> values in all hard registers involved.
That's not clear to me: for example in move2add_not
The problem was that we had some optimzations added to the reload_cse_move2add
pass that would attempt transformations with multi-hard-register registers,
without keeping track of the validity of the values in all hard registers
involved.
The attached patch fixes this by updating reg_set_luid for
11 matches
Mail list logo
