This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: PR target/47715: [x32] Use SImode for thread pointer


On Thu, Jul 28, 2011 at 8:30 PM, H.J. Lu <hjl.tools@gmail.com> wrote:

>>>>> TP is 32bit in x32 ?For load_tp_x32, we load SImode value and
>>>>> zero-extend to DImode. For add_tp_x32, we are adding SImode
>>>>> value. ?We can't pretend TP is 64bit. ?load_tp_x32 and add_tp_x32
>>>>> must take SImode TP.
>>>>>
>>>>
>>>> I will see what I can do.
>>>>
>>>
>>> Here is the updated patch to use 32bit TP for 32.
>>
>> Why??
>>
>> This part makes no sense:
>>
>> - ?tp = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, const0_rtx), UNSPEC_TP);
>> + ?tp = gen_rtx_UNSPEC (ptr_mode, gen_rtvec (1, const0_rtx), UNSPEC_TP);
>> + ?if (ptr_mode != Pmode)
>> + ? ?tp = convert_to_mode (Pmode, tp, 1);
>>
>> You will create zero_extend (unspec ...), that won't be matched by any pattern.
>
> No. ?I created ?zero_exten from (reg:SI) to (reg: DI).
>
>> Can you please explain, how is this pattern different than DImode
>> pattern, proposed in my patch?
>>
>> +(define_insn "*load_tp_x32"
>> + ?[(set (match_operand:SI 0 "register_operand" "=r")
>> + ? ? ? (unspec:SI [(const_int 0)] UNSPEC_TP))]
>> + ?"TARGET_X32"
>> + ?"mov{l}\t{%%fs:0, %0|%0, 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")])
>>
>> vs:
>>
>> +(define_insn "*load_tp_x32"
>> + ?[(set (match_operand:DI 0 "register_operand" "=r")
>> + ? ? ? (unspec:DI [(const_int 0)] UNSPEC_TP))]
>
> That is wrong since source (TP) ?is 32bit. ?This pattern tells compiler
> source is 64bit.

Where?

Uros.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]