Impact assessment of dse.c:emit_inc_dec_insn_before (Was: Re: Use of FLAGS_REGNUM clashes with generates insn)

[Joern Rennecke]

Quoting amylaar@spamcop.net:
> The issue with this patch is that we'll have to check if gen_add3_insn might
> fail on any target, and also we have to identify on which targets it will
> create an insn that clobbers potentially live hard registers
> (like a flags register), and make the substitution fail in this case.
> I.e. if in doubt, keep the dead store with the auto-increment.
> But not fail for a target that knows what it clobbers in a
> reload_in_progress / reload_completed add.

I've gone through the machine description that define one of the
HAVE_P\(RE\|OST\)_.* macros, and checked if the auto-increment addresses
they accept can be replaced with an add, both when using gen_add3_insn,
which goes via optabs and named patterns, and by recognizing the
rtl that dse.c:emit_inc_dec_insn_before generates without any proper checks.

I've added the maintainers of ports that appear to get auto-increments
turned into flag-clobbering adds (excluding cc0) to the Cc: list.

Note that the auto-increment offset range in this summary only states what
the GCC machine description says; for various reasons, the actual hardware
capabilities might be more or less.
"insn pattern" means that the add pattern for Pmode (one of addhi3 / addsi3 /
adddi3 / addpsi3) is a named instruction patterns and is thus used both when
expanding using gen_add3_insn, and to recognize the add.
I have looked at the offset range for any auto-increment use, even though
at times only a smaller range is available for stores; it turned out that
the addition range is not actually a problem for the existing targets.

architecture    Pmode   offset     addP3 src,src,srcoff
with PRE/POST
INC/DEC/MODIFY
arm            SImode  -255..255       expand, recog OK.
arm            SImode (-255..255)*4    expand, recog OK.
avr            HImode -4..4            expand, recog OK (costly & need cc0)
bfin           SImode -8..8            insn pattern, breaks on IREGS, PDImode.
c6x            SImode -8..8            insn pattern, breaks on REG_ILC
cris           SImode  1..8            expand, recog OK.
frv            SImode  reg only        insn pattern, OK.
h8300   HImode/SImode -4..+4           expand, recog OK.
ia64           DImode -256..255        insn pattern, OK.
m32c   HImode/PSImode -8..8/NaN        insn pattern, OK if offset is operand.
m32r           SImode -4/4             insn pattern, OK.
m68k           SImode -8..8            expand, recog OK.
mn10300        SImode any integer      insn pattern, has CC_REG clobber.
                                        recog of naked (set ...  
(plus)) will fail
pa             SImode -8..8            insn pattern, OK.
pa             DImode -8..8            expand, recog OK.
pdp11          HImode -8..8            insn pattern, OK.
rs6000  SImode/DImode -0x8000..0x7fff  expand, recog OK.
rx             SImode -4..4            expand, recog with CC_REG clobber.
                                        recog of naked (set ...  
(plus)) will fail
score          SImode -4..4            expand, recog OK.
sh             SImode -8..8            expand, recog OK.
sh64           DImode N/A
stormy16       HImode any integer      insn pattern, has CARRY_REG clobber.
                 ALL REGISTERS ARE ALLOWED AS ADDRESS REGISTERS,
                 BUT ONLY TWO CAN BE USED IN AN ADD INSN.  Calling gen_addhi3
                 with a non-general register operand after reload will generate
                 an insn that fails to match its constraints.
vax            SImode -8..8            insn pattern, OK.

m32c.c:m32c_legitimate_address_p allows any rubbish inside a PRE_MODIFY,
as long as the address register is the stack pointer.
OTOH, it does not define any HAVE_*_MODIFY_* macro.

score defines HAVE_PRE_MODIFY_DISP and HAVE_POST_MODIFY_DISP, but rejects
PRE_MODIFY / POST_MODIFY in TARGET_LEGITIMATE_ADDRESS_P .

It appears the dse problem can currently cause ICE-on-valid for  
mn10300 and rx,
which could be changed by my original patch into sporadic
wrong-code generation, when CC_REG happens to be live.  OTOH when CC_REG
is free, we get working code instead of the ICE.
The situation is similar for stormy16 unless a register is used as an
address register that is not suitable for an add - which would continue to
get ICEs.