Re: How to target a processor with very primitive addressing modes?
On Thu, Jun 6, 2024 at 8:59 PM Dimitar Dimitrov 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 addptr3 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 add3 insn clobbers the CC register. The docs say to define addptr3 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
ਪੀਜੀਐਨਪੀ
Sent from my iPhone
Re: How to target a processor with very primitive addressing modes?
On 6/8/24 3:32 AM, Mikael Pettersson via Gcc wrote: On Thu, Jun 6, 2024 at 8:59 PM Dimitar Dimitrov 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 addptr3 insn. If it doesn't work without TARGET_LEGITIMATE_ADDRESS, then it's wrong. At the highest level that hook is meant to provide a way for the target to adjust addresses to optimize them better. If you're using it for correctness purposes, it's ultimately going to fail in one way or another. GCC has certainly supported targets with limited addressing modes in the past (ia64 being a good example). It's painful to deal with such targets, but it can be made to work. Jeff
Re: How to target a processor with very primitive addressing modes?
> On Jun 8, 2024, at 5:32 AM, Mikael Pettersson via Gcc wrote: > > On Thu, Jun 6, 2024 at 8:59 PM Dimitar Dimitrov 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 > addptr3 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 add3 insn clobbers the CC register. The docs say to define > addptr3 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. paul
Re: How to target a processor with very primitive addressing modes?
On 6/8/24 10:45 AM, Paul Koning via Gcc wrote: On Jun 8, 2024, at 5:32 AM, Mikael Pettersson via Gcc wrote: On Thu, Jun 6, 2024 at 8:59 PM Dimitar Dimitrov 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 addptr3 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 add3 insn clobbers the CC register. The docs say to define addptr3 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
Re: How to target a processor with very primitive addressing modes?
> On Jun 8, 2024, at 1:12 PM, Jeff Law wrote: > > > > On 6/8/24 10:45 AM, Paul Koning via Gcc wrote: >>> On Jun 8, 2024, at 5:32 AM, Mikael Pettersson via Gcc >>> wrote: >>> >>> On Thu, Jun 6, 2024 at 8:59 PM Dimitar Dimitrov 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 >>> addptr3 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 add3 insn clobbers the CC register. The docs say to define >>> addptr3 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 I remember working through all that in the CC0 to CCmode transition, though I didn't notice any new issues with LRA (in pdp11, LRA conversion simply amounted to turning it on). The CC0 conversion documentation, as I recall, speaks of two flavors of targets, and two different ways of managing CC in the MD file. PDP11 is the type of target where all ALU operations update CC, so in particular there is no way to do address arithmetic beyond what the addressing modes do, without affecting CC. The style of CC description I used given that guidance works just fine. paul
gcc-14-20240608 is now available
Snapshot gcc-14-20240608 is now available on https://gcc.gnu.org/pub/gcc/snapshots/14-20240608/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 14 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-14 revision c3e16edcf2c8429da2cb479d8941397f4300e0c4 You'll find: gcc-14-20240608.tar.xz Complete GCC SHA256=964189d91fc4455b27c948c7aaaefe583100d04d6d96749c38be8e4a8054be83 SHA1=32a06a7e3ff60ff67f99f95fd2940d7a03a5320a Diffs from 14-20240601 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-14 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
