On Tue, Mar 27, 2012 at 9:37 AM, Uros Bizjak <ubiz...@gmail.com> wrote:
> On Tue, Mar 27, 2012 at 6:13 PM, Ulrich Weigand <uweig...@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.

As I explained in:


we can remove *load_tp_x32_zext and use

(define_insn "*load_tp_x32_<mode>"
  [(set (match_operand:SWI48x 0 "register_operand" "=r")
        (unspec:SWI48x [(const_int 0)] UNSPEC_TP))]
  "mov{l}\t{%%fs:0, %k0|%k0, DWORD PTR fs:0}"
  [(set_attr "type" "imov")
   (set_attr "modrm" "0")
   (set_attr "length" "7")
   (set_attr "memory" "load")
   (set_attr "imm_disp" "false")])

to load %fs directly into %r32 or %r64.


Reply via email to