On Thu, Jul 28, 2011 at 8:03 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>>>>> So, instead of huge complications with new mode iterator, just
>>>>>> introduce two new patterns that will shadow existing ones for
>>>>>> TARGET_X32.
>>>>>>
>>>>>> Like in attached (untested) patch.
>>>>>>
>>>>>
>>>>> I tried the following patch with typos fixed. It almost worked,
>>>>> except for this failure in glibc testsuite:
>>>>>
>>>>> gen-locale.sh: line 27: 14755 Aborted (core dumped)
>>>>> I18NPATH=. GCONV_PATH=${common_objpfx}iconvdata ${localedef} --quiet
>>>>> -c -f $charmap -i $input ${common_objpfx}localedata/$out
>>>>> Charmap: "ISO-8859-1" Inputfile: "nb_NO" Outputdir: "nb_NO.ISO-8859-1"
>>>>> failed
>>>>> make[4]: ***
>>>>> [/export/build/gnu/glibc-x32/build-x86_64-linux/localedata/nb_NO.ISO-8859-1/LC_CTYPE]
>>>>> Error 1
>>>>>
>>>>> I will add:
>>>>>
>>>>> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
>>>>> index 8723dc5..d32d64d 100644
>>>>> --- a/gcc/config/i386/i386.c
>>>>> +++ b/gcc/config/i386/i386.c
>>>>> @@ -12120,7 +12120,9 @@ get_thread_pointer (bool to_reg)
>>>>> {
>>>>> rtx tp, reg, insn;
>>>>>
>>>>> - 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);
>>>>> if (!to_reg)
>>>>> return tp;
>>>>>
>>>>> since TP must be 32bit.
>>>>
>>>> No, this won't have the desired effect. It will change the UNSPEC, so
>>>> it won't match patterns in i386.md.
>>>>
>>>> Can you debug the failure a bit more? With my patterns, add{l} and
>>>> mov{l} should clear top 32bits.
>>>>
>>>
>>> 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.
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))]
+ "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")])
Uros.
