Uros Bizjak wrote: > In a corner case of a reload, reload pass can generate partially > reloaded address, where not all registers get allocated to a hard reg. > When this address is checked with ix86_legitimate_address, it is > rejected, since in strict mode, pseudos are not valid address > registers. So, reload tries to legitimize following (partially > invalid) address: > > (plus:DI (plus:DI (unspec:DI [(const_int 0 [0])] UNSPEC_TP) > (reg:DI 97)) > (reg:DI 2 cx)) > > via generic way by pushing all components into a register, forming > (even more invalid) address that involves three registers (r8, r9 and > rcx): [snip]
> Since fixing reload issues is some kind of black magic, I'd like to > ask Ulrich and Richard for their opinion on this approach. Well, generally speaking, reload makes a lot of assumptions on how addresses can look like; it needs to, since if a target rejects an address as invalid as-is, reload must fix it up -- and it can do so only by making assumptions ... Allowing a random UNSPEC as part of valid (non-strict) addresses makes it really impossible for reload to understand what's going on. Given that, I'd tend to agree that *if* you do that, you then also have to help reload how to deal with such addresses by providing a legitimize_reload_address hook as you did. Now, in this particular case, there might be another option to avoid this hassle completely: I understand that this UNSPEC is simply a magic marker to make the address use the fs: or gs: segment override, right? Now that GCC supports address spaces, it might be possible to model fs:/gs: relative addresses instead by using a non-standard address space ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
