Philip Pemberton <phil...@gmail.com> writes: >> The address is unusual: >> >> (subreg:SI (mem/s:DI (plus:SI (reg/v/f:SI 39 [ ctx ]) >> (const_int 64 [0x40])) [0 S8 A64]) 4) >> >> Why isn't that simply >> >> (mem/s:SI (plus:SI (reg/v/f:SI 39 [ ctx ]) >> (const_int 68 [0x40])) [0 S8 A64]) > > Let me see if I understand this right... > > It's using an SImode (machine-native size, 32 bit) subreg over a > DImode (DWORD, 64bit) address of a 32-bit addition operation? That > can't be right...
This means that it is taking an SImode slice out of a DImode value. >> That makes it look like something is creating a subreg without going >> through simplify_gen_subreg. >> >> It's also possible that the problem is simply that >> lm32_legitimate_address_p needs to handle a SUBREG memory address. > > The questions raised by that would be: > 1) Where is the subreg being created? (or: "how can a subreg be > created?" -- then grep the lm32 source for the answer(s) to that > question) I don't know where the subreg is being created. There are several different ways to create one. > 2) (assuming [1] isn't the problem) How do you handle a SUBREG in > *_legitimate_address_p? In *_legitimate_address_p you can usually do something along the lines of if (GET_CODE (x) == SUBREG) x = SUBREG_REG (x); However, as I mentioned, this whole SUBREG is odd, so it's first necessary to find out whether it should have been created at all. Ian