[PATCH, i386]: FIX PR 52698, reload failure with complex address

Uros Bizjak ubizjak@gmail.com
Tue Mar 27 16:37:00 GMT 2012


On Tue, Mar 27, 2012 at 6:13 PM, Ulrich Weigand <uweigand@de.ibm.com> wrote:

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

This is an interesting idea, I will look into it.

(BTW: For now, I have just committed the proposed fixup).

Thanks,
Uros.



More information about the Gcc-patches mailing list