This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Impact assessment of dse.c:emit_inc_dec_insn_before (Was: Re: Use of FLAGS_REGNUM clashes with generates insn)
Quoting DJ Delorie <dj@redhat.com>:
I was talking about what addresses are allowed by the
TARGET_LEGITIMATE_ADDRESS_P, not what the hardware implements or
what the register allocator is guided to produce; some optimizers
can get quite 'creative' in mashing rtl together.
I've never seen it actually do that and get it past the backend, but
if they're doing it now, I suppose that logic is no longer sufficient.
Well, this pattern was freely invented, but I've seen the combiner
folding arithmetic and other memory references in place of a register
inside a memory address when you give it the opportunity (for a different
port). Operand predicates matter, and what memory_operand /
address_operand accept is largely determined by TARGET_LEGITIMATE_ADDRESS_P.
But my original point wasn't so much about this potential/latent problem
in the m32c port as such, as that this is a pathway by which
dse.c:emit_inc_dec_insn_before could find itself with some mighty
strange
autoincrement addresses which it would attempt to convert to additions.
These would generally not be recognized by the addition - or any other
existing - patterns. However, if we discount these weird patterns -
be that because 'that never happens' or because they are blocked by a few
more checks in the target hook, so that the offset in a recognized PRE_MODIFY
is always a valid operand, the m32c addhi3 insn pattern will work, no
matter if you go the optabs route, or use the current raw rtl generation
in dse.c:emit_inc_dec_insn_before .
OTOH, if the PRE_MODIFY is malformed, you are likely to end up with an ICE,
no matter which way you try to make it into an add, and even if you leave it
alone, it is not likely to end in the successful generation of a working
program. So, although the analysis shows the m32c is not entirely in the
clear with regards to the dead store with auto-increment -> add
transformation,
and problem there is not really a dse problem.
mn10300, rx and stormy16 show a problem with a flags register clobber.
If the avr wanted to sched cc0, it would join these ranks.
The Epiphany has the further interesting aspect that some additions that can
be done with a post_modify have a wider offset range than an add.