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):

> 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 ...


  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE

Reply via email to