Thanks for you info Julian. I actually read all the docs and I think I 'more or less' understand the inner workings of gcc. What surprises me most is that during the non-strict RTL generation I do not see any 'strange' address pattern but during the post-reload process the non-legitimate address comes up. I guess it is due to the fact that one of the PLUS operands is a memory operand (a local var.?), thus resulting in double indirect memory address.
In any case I'm not using the restrict variable and I'm assuming strict is zero, this is, not checking the hard regsiters themselves. This is because any reg is OK for base reg. I'm pretty sure I'm behaving similarly to arm, cris or x86 backends. Thanks, David 2014-03-14 13:11 GMT+01:00 Julian Brown <jul...@codesourcery.com>: > On Fri, 14 Mar 2014 12:52:35 +0100 > David Guillen <da...@davidgf.net> wrote: > >> If I allow also a 'PLUS' expression to be a valid address (adding the >> restriction that the two addends are a register and a constant) it >> happens (sometimes) that gcc comes up with an expression like this >> one: >> >> (plus:SI (plus:SI (reg:SI somereg) >> (const_int 4)) >> (const_int 8)) >> >> >> After taking a look at the 386 backend (and others) I just discovered >> that there is a function called LEGITIMIZE_RELOAD_ADDRESS which is >> responsible for handling this case. My issue is that this function is >> not being called and, from what I saw while debugging, it seems that >> the offending RTX expression is created after the address_reload pass, >> and thus impossible for this pass to legitimize the address. > > Look at how e.g. the ARM backend and others handle the "strict" > parameter to the legitimate_address hook -- you need to use that to > forbid pseudo registers being allowed in RTXs in the strict case. > LEGITIMIZE_RELOAD_ADDRESS is probably a red herring (at least for the > simple cases you're probably dealing with to start with), and isn't used > for LRA anyway. Getting these bits right can be very fiddly! The (plus > (reg) (const)) operands can arise before/during during register > elimination, IIRC. (You might need to get the register-elimination bits > right, too...) > > Just a guess, anyway. (http://gcc.gnu.org/wiki/reload might be helpful > if you've not read it.) > > Julian
