On Tue, Mar 27, 2012 at 9:57 AM, Uros Bizjak <ubiz...@gmail.com> wrote:
> On Tue, Mar 27, 2012 at 6:57 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>
>>>> 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:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01590.html
>>
>> 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))]
>> "TARGET_X32"
>> "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.
>
> No, we can't.
>
GCC needs to move the value in the %fs segment
register into %r32 or %r64. This instruction
"mov{l}\t{%%fs:0, %k0|%k0, DWORD PTR fs:0}"
does exactly what GCC wants.
--
H.J.
