On Sat, Jun 8, 2024 at 5:11 PM Jeff Law <jeffreya...@gmail.com> wrote: > > > > On 6/8/24 3:32 AM, Mikael Pettersson via Gcc 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. > 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.
My target is the RCA CDP1802. 8-bit bytes, 16-bit address space, sixteen 16-bit address registers, one 8-bit accumulator through which all data movement and arithmetic happens, one 1-bit carry/borrow flag, and two 4-bit register selector registers, one of which selects which address register is PC, the other which register is used with the "stack push" instruction and a few others. It's an odd and very primitive beast. My first attempt was just following the gcc internals docs and extrapolating from other targets, but that failed with reload loops as soon as it started building libgcc. So I scrapped that and took the stormy16 port, simplified and tweaked it to the point where it semantically matched my target, and then changed the rest over to be CDP1802-specific. This works well enough to build libgcc including soft-fp. The main omissions are frame layout which still is for the stormy16, and target-specific support routines in libgcc for things that are just too awkward to generate code for. The code can be found on github, if anyone is interested: > git clone -b cdp1802 https://github.com/mikpe/binutils-gdb.git > git clone -b cdp1802 https://github.com/mikpe/gcc.git The target is cdp1802-unknown-elf , and gcc also wants --with-newlib --enable-languages=c --disable-libssp. Pending work includes: - fixing the frame layout - support for targeting the CDP1804/05/06 which adds some register data movement operations that don't need to go via the 8-bit accumulator - seeing if I can get rid of addptrhi3 - seeing if I can expose the register selector register X so that gcc can eliminate redundant assignments to it - update the simulator to run ELF executables not just Intel HEX files - run the test suite /Mikael
