On 6/8/24 10:45 AM, Paul Koning via Gcc wrote:
On Jun 8, 2024, at 5:32 AM, Mikael Pettersson via Gcc <gcc@gcc.gnu.org> wrote:
On Thu, Jun 6, 2024 at 8:59 PM Dimitar Dimitrov <dimi...@dinux.eu> wrote:
Have you tried defining TARGET_LEGITIMIZE_ADDRESS for your target? From
a quick search I see that the iq2000 and rx backends are rewriting some
PLUS expression addresses with insn sequence to calculate the address.
I have partial success.
The key was to define both TARGET_LEGITIMATE_ADDRESS_P and an
addptr<Pmode>3 insn.
I had tried TARGET_LEGITIMATE_ADDRESS_P before, together with various
combinations of TARGET_LEGITIMIZE_ADDRESS and
LEGITIMIZE_RELOAD_ADDRESS, but they all threw gcc into reload loops.
My add<Pmode>3 insn clobbers the CC register. The docs say to define
addptr<Pmode>3 in this case, and that eliminated the reload loops.
The issue now is that the machine cannot perform an add without
clobbering the CC register, so I'll have to hide that somehow. When
emitting the asm code, can one check if the CC register is LIVE-OUT
from the insn? If it isn't I shouldn't have to generate code to
preserve it.
/Mikael
I'm not sure why add that clobbers CC requires anything special (other than of
course showing the CC register as clobbered in the definition). pdp11 is
another target that only has a CC-clobbering add. Admittedly, it does have
register+offset addressing modes, but still the reload machinery deals just
fine with add operations like that.
If he's got a CC register exposed prior to LRA and LRA needs to insert
any code, that inserted code may clobber the CC state. This is
discussed in the reload-to-LRA transition wiki page.
jeff
