This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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
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.
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

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]