On Thu, Jul 28, 2011 at 8:30 PM, H.J. Lu <hjl.to...@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.