On Tue, Mar 20, 2012 at 11:43 AM, Uros Bizjak wrote:
> On Tue, Mar 20, 2012 at 7:27 PM, H.J. Lu wrote:
>
I think use the OS provided instruction to load TP into DImode register
could simplify the code.
>>>
>>> Which OS provided instruction?
>>>
>>> Please see how TP is defined in get_th
On Tue, Mar 20, 2012 at 7:27 PM, H.J. Lu wrote:
>>> I think use the OS provided instruction to load TP into DImode register
>>> could simplify the code.
>>
>> Which OS provided instruction?
>>
>> Please see how TP is defined in get_thread_pointer, it is in ptr_mode:
>>
>> rtx tp = gen_rtx_UNSPEC
On Tue, Mar 20, 2012 at 10:54 AM, Uros Bizjak wrote:
> On Tue, Mar 20, 2012 at 4:52 PM, H.J. Lu wrote:
>
Yeah, my bootstrap just failed the same. Will test:
2012-03-20 Jakub Jelinek
* config/i386/i386.c (ix86_decompose_address) :
If operand isn't UNSP
On Tue, Mar 20, 2012 at 4:52 PM, H.J. Lu wrote:
>>> Yeah, my bootstrap just failed the same. Will test:
>>>
>>> 2012-03-20 Jakub Jelinek
>>>
>>> * config/i386/i386.c (ix86_decompose_address) :
>>> If operand isn't UNSPEC, return 0.
>>
>> Committed as obvious now that bootstrap/reg
On Tue, Mar 20, 2012 at 4:19 AM, Jakub Jelinek wrote:
> On Tue, Mar 20, 2012 at 09:58:29AM +0100, Jakub Jelinek wrote:
>> Yeah, my bootstrap just failed the same. Will test:
>>
>> 2012-03-20 Jakub Jelinek
>>
>> * config/i386/i386.c (ix86_decompose_address) :
>> If operand isn't UNS
On Tue, Mar 20, 2012 at 09:58:29AM +0100, Jakub Jelinek wrote:
> Yeah, my bootstrap just failed the same. Will test:
>
> 2012-03-20 Jakub Jelinek
>
> * config/i386/i386.c (ix86_decompose_address) :
> If operand isn't UNSPEC, return 0.
Committed as obvious now that bootstrap/regte
Il 19/03/2012 20:13, Uros Bizjak ha scritto:
> 2012-03-19 Uros Bizjak
>
> * config/i386/i386.c (get_thread_pointer): Add tp_mode argument.
> Generate ZERO_EXTEND in place if GET_MODE (tp) != tp_mode.
> (legitimize_tls_address) : Always generate
> DImode UNSPEC_GOTNTPOFF
On Tue, Mar 20, 2012 at 09:51:07AM +0100, Eric Botcazou wrote:
> > The patch is bootstrapping now on x86_64-pc-linux-gnu.
>
> It very likely breaks bootstrap with RTL checking enabled:
>
> /sil.a/gnatmail/gnatmail-x/build-sil/x86-linux/gnat/obj/./gcc/xgcc
> -B/sil.a/gnatmail/gnatmail-x/build-sil
> The patch is bootstrapping now on x86_64-pc-linux-gnu.
It very likely breaks bootstrap with RTL checking enabled:
/sil.a/gnatmail/gnatmail-x/build-sil/x86-linux/gnat/obj/./gcc/xgcc
-B/sil.a/gnatmail/gnatmail-x/build-sil/x86-linux/gnat/obj/./gcc/
-B/usr/gnat/i686-pc-linux-gnu/bin/ -B/usr/gnat/
On Mon, Mar 19, 2012 at 6:50 PM, H.J. Lu wrote:
>>> Please test my proposed patch. If it works OK, I will commit it to SVN.
>>
>> The onyl acceptable way is to generate ZERO_EXTEND in place, so:
>>
>> --cut here--
>> static rtx
>> get_thread_pointer (enum machine_mode tp_mode, bool to_reg)
>> {
>
On Mon, Mar 19, 2012 at 10:29 AM, Uros Bizjak wrote:
> On Mon, Mar 19, 2012 at 6:01 PM, Uros Bizjak wrote:
> For x32, thread pointer is an unsigned 32bit value.
>
> movl %fs:0, %eax
>
> is the correct instruction to load thread pointer into EAX and RAX.
So, where is
On Mon, Mar 19, 2012 at 6:01 PM, Uros Bizjak wrote:
For x32, thread pointer is an unsigned 32bit value.
movl %fs:0, %eax
is the correct instruction to load thread pointer into EAX and RAX.
>>>
>>> So, where is ZERO_EXTEND RTX then?
>>>
>>
>> Thread pointer (TP) is an opaq
On Mon, Mar 19, 2012 at 5:55 PM, H.J. Lu wrote:
>>> For x32, thread pointer is an unsigned 32bit value.
>>>
>>> movl %fs:0, %eax
>>>
>>> is the correct instruction to load thread pointer into EAX and RAX.
>>
>> So, where is ZERO_EXTEND RTX then?
>>
>
> Thread pointer (TP) is an opaque value to G
On Mon, Mar 19, 2012 at 9:49 AM, Uros Bizjak wrote:
> On Mon, Mar 19, 2012 at 5:47 PM, H.J. Lu wrote:
>
>> For x32, thread pointer is an unsigned 32bit value.
>>
>> movl %fs:0, %eax
>>
>> is the correct instruction to load thread pointer into EAX and RAX.
>
> So, where is ZERO_EXTEND RTX then?
>
On Mon, Mar 19, 2012 at 5:47 PM, H.J. Lu wrote:
> For x32, thread pointer is an unsigned 32bit value.
>
> movl %fs:0, %eax
>
> is the correct instruction to load thread pointer into EAX and RAX.
So, where is ZERO_EXTEND RTX then?
Uros.
On Mon, Mar 19, 2012 at 5:19 PM, H.J. Lu wrote:
> movl %fs:0, %eax
> movq c@gottpoff(%rip), %rdx
> movzbl (%rax,%rdx), %edx
> movb %dl, y(%rip)
> movq w@gottpoff(%rip), %rdx
> movzwl (%rax,%rdx), %eax
> movw %ax, i(%rip)
> r
On Mon, Mar 19, 2012 at 9:37 AM, Uros Bizjak wrote:
> On Mon, Mar 19, 2012 at 5:34 PM, H.J. Lu wrote:
>
Combine failed:
(set (reg:QI 63 [ c ])
(mem/c:QI (plus:DI (zero_extend:DI (unspec:SI [
(const_int 0 [0])
] UNSPEC_TP))
On Mon, Mar 19, 2012 at 5:34 PM, H.J. Lu wrote:
>>> Combine failed:
>>>
>>> (set (reg:QI 63 [ c ])
>>> (mem/c:QI (plus:DI (zero_extend:DI (unspec:SI [
>>> (const_int 0 [0])
>>> ] UNSPEC_TP))
>>> (mem/u/c:DI (const:DI (unspec:DI [
>>>
On Mon, Mar 19, 2012 at 9:19 AM, H.J. Lu wrote:
> On Mon, Mar 19, 2012 at 8:54 AM, H.J. Lu wrote:
>> On Mon, Mar 19, 2012 at 8:51 AM, H.J. Lu wrote:
>>> On Sun, Mar 18, 2012 at 1:55 PM, Uros Bizjak wrote:
On Sun, Mar 18, 2012 at 5:01 PM, Uros Bizjak wrote:
>> I am testing this pa
On Mon, Mar 19, 2012 at 8:54 AM, H.J. Lu wrote:
> On Mon, Mar 19, 2012 at 8:51 AM, H.J. Lu wrote:
>> On Sun, Mar 18, 2012 at 1:55 PM, Uros Bizjak wrote:
>>> On Sun, Mar 18, 2012 at 5:01 PM, Uros Bizjak wrote:
>>>
> I am testing this patch. OK for trunk if it passes all tests?
No,
On Mon, Mar 19, 2012 at 8:51 AM, H.J. Lu wrote:
> On Sun, Mar 18, 2012 at 1:55 PM, Uros Bizjak wrote:
>> On Sun, Mar 18, 2012 at 5:01 PM, Uros Bizjak wrote:
>>
I am testing this patch. OK for trunk if it passes all tests?
>>>
>>> No, force_reg will generate a pseudo, so this conversion is
On Sun, Mar 18, 2012 at 1:55 PM, Uros Bizjak wrote:
> On Sun, Mar 18, 2012 at 5:01 PM, Uros Bizjak wrote:
>
>>> I am testing this patch. OK for trunk if it passes all tests?
>>
>> No, force_reg will generate a pseudo, so this conversion is valid only
>> for !can_create_pseudo ().
>>
>> At least
On Sun, Mar 18, 2012 at 5:01 PM, Uros Bizjak wrote:
>> I am testing this patch. OK for trunk if it passes all tests?
>
> No, force_reg will generate a pseudo, so this conversion is valid only
> for !can_create_pseudo ().
>
> At least for *tls_initial_exec_x32_store, you will need a temporary to
On Sat, Mar 17, 2012 at 10:50 PM, H.J. Lu wrote:
> Since we must use reg64 in %fs:(%reg) memory operand like
>
> movq x@gottpoff(%rip),%reg64;
> mov %fs:(%reg64),%reg
>
> this patch optimizes x32 TLS IE load and store by wrapping
> %reg64 inside of UNSPEC when Pmode ==
On Sat, Mar 17, 2012 at 11:20 AM, Uros Bizjak wrote:
> On Sat, Mar 17, 2012 at 7:18 PM, H.J. Lu wrote:
>
Since we must use reg64 in %fs:(%reg) memory operand like
movq x@gottpoff(%rip),%reg64;
mov %fs:(%reg64),%reg
this patch optimizes x32 TLS IE load and store by wr
On Sat, Mar 17, 2012 at 7:18 PM, H.J. Lu wrote:
>>> Since we must use reg64 in %fs:(%reg) memory operand like
>>>
>>> movq x@gottpoff(%rip),%reg64;
>>> mov %fs:(%reg64),%reg
>>>
>>> this patch optimizes x32 TLS IE load and store by wrapping
>>> %reg64 inside of UNSPEC when Pmode == SImode. OK fo
On Sat, Mar 17, 2012 at 11:10 AM, Uros Bizjak wrote:
> On Sun, Mar 11, 2012 at 6:11 PM, H.J. Lu wrote:
>
>> Since we must use reg64 in %fs:(%reg) memory operand like
>>
>> movq x@gottpoff(%rip),%reg64;
>> mov %fs:(%reg64),%reg
>>
>> this patch optimizes x32 TLS IE load and store by wrapping
>> %r
On Sun, Mar 11, 2012 at 6:11 PM, H.J. Lu wrote:
> Since we must use reg64 in %fs:(%reg) memory operand like
>
> movq x@gottpoff(%rip),%reg64;
> mov %fs:(%reg64),%reg
>
> this patch optimizes x32 TLS IE load and store by wrapping
> %reg64 inside of UNSPEC when Pmode == SImode. OK for
> trunk?
>
>
On Tue, Mar 13, 2012 at 3:37 AM, Uros Bizjak wrote:
> On Tue, Mar 13, 2012 at 8:11 AM, Uros Bizjak wrote:
>
> Please try attached patch. It introduces TARGET_TLS_INDIRECT_SEG_REFS
> to block only indirect seg references.
>>>
>>> There is no regression.
>>
>> Thanks, committed to mainline
On Tue, Mar 13, 2012 at 3:37 AM, Uros Bizjak wrote:
> On Tue, Mar 13, 2012 at 8:11 AM, Uros Bizjak wrote:
>
> Please try attached patch. It introduces TARGET_TLS_INDIRECT_SEG_REFS
> to block only indirect seg references.
>>>
>>> There is no regression.
>>
>> Thanks, committed to mainline
On Tue, Mar 13, 2012 at 8:11 AM, Uros Bizjak wrote:
Please try attached patch. It introduces TARGET_TLS_INDIRECT_SEG_REFS
to block only indirect seg references.
>>
>> There is no regression.
>
> Thanks, committed to mainline SVN with following ChangeLog:
>
> 2012-03-13 Uros Bizjak
>
On Tue, Mar 13, 2012 at 2:20 AM, H.J. Lu wrote:
Here is the patch which is equivalent to clearing MASK_TLS_DIRECT_SEG_REFS
when Pmode != word_mode. We need to keep
else if (Pmode == SImode)
{
/* Always generate
On Mon, Mar 12, 2012 at 3:35 PM, H.J. Lu wrote:
> On Mon, Mar 12, 2012 at 12:39 PM, Uros Bizjak wrote:
>> On Sun, Mar 11, 2012 at 10:24 PM, H.J. Lu wrote:
>>
>>> Here is the patch which is equivalent to clearing MASK_TLS_DIRECT_SEG_REFS
>>> when Pmode != word_mode. We need to keep
>>>
>>>
On Mon, Mar 12, 2012 at 12:39 PM, Uros Bizjak wrote:
> On Sun, Mar 11, 2012 at 10:24 PM, H.J. Lu wrote:
>
>> Here is the patch which is equivalent to clearing MASK_TLS_DIRECT_SEG_REFS
>> when Pmode != word_mode. We need to keep
>>
>> else if (Pmode == SImode)
>> {
>>
On Sun, Mar 11, 2012 at 10:24 PM, H.J. Lu wrote:
> Here is the patch which is equivalent to clearing MASK_TLS_DIRECT_SEG_REFS
> when Pmode != word_mode. We need to keep
>
> else if (Pmode == SImode)
> {
> /* Always generate
> movl %fs:0, %r
On Sun, Mar 11, 2012 at 11:21 AM, Uros Bizjak wrote:
> On Sun, Mar 11, 2012 at 7:16 PM, H.J. Lu wrote:
>
>>> * config/i386/i386.c (ix86_decompose_address): Disallow fs:(reg)
>>> if Pmode != word_mode.
>>> (legitimize_tls_address): Call gen_tls_initial_exec_x32 if
On Sun, Mar 11, 2012 at 7:16 PM, H.J. Lu wrote:
>> * config/i386/i386.c (ix86_decompose_address): Disallow fs:(reg)
>> if Pmode != word_mode.
>> (legitimize_tls_address): Call gen_tls_initial_exec_x32 if
>> Pmode == SImode for x32.
>>
>>
On Sun, Mar 11, 2012 at 10:55 AM, Uros Bizjak wrote:
> On Sun, Mar 11, 2012 at 6:11 PM, H.J. Lu wrote:
>
> X86-64 linker optimizes TLS_MODEL_INITIAL_EXEC to TLS_MODEL_LOCAL_EXEC
> by checking
>
> movq foo@gottpoff(%rip), %reg
>
> and
On Sun, Mar 11, 2012 at 6:11 PM, H.J. Lu wrote:
X86-64 linker optimizes TLS_MODEL_INITIAL_EXEC to TLS_MODEL_LOCAL_EXEC
by checking
movq foo@gottpoff(%rip), %reg
and
addq foo@gottpoff(%rip), %reg
>>>
On Sat, Mar 10, 2012 at 10:49 AM, H.J. Lu wrote:
> On Sat, Mar 10, 2012 at 5:09 AM, Uros Bizjak wrote:
>> On Fri, Mar 9, 2012 at 11:26 PM, H.J. Lu wrote:
>>> On Mon, Mar 5, 2012 at 9:25 AM, Uros Bizjak wrote:
On Mon, Mar 5, 2012 at 6:03 PM, H.J. Lu wrote:
>>> X86-64 linker optimi
On Sat, Mar 10, 2012 at 5:09 AM, Uros Bizjak wrote:
> On Fri, Mar 9, 2012 at 11:26 PM, H.J. Lu wrote:
>> On Mon, Mar 5, 2012 at 9:25 AM, Uros Bizjak wrote:
>>> On Mon, Mar 5, 2012 at 6:03 PM, H.J. Lu wrote:
>>>
>> X86-64 linker optimizes TLS_MODEL_INITIAL_EXEC to TLS_MODEL_LOCAL_EXEC
>>
On Fri, Mar 9, 2012 at 11:26 PM, H.J. Lu wrote:
> On Mon, Mar 5, 2012 at 9:25 AM, Uros Bizjak wrote:
>> On Mon, Mar 5, 2012 at 6:03 PM, H.J. Lu wrote:
>>
> X86-64 linker optimizes TLS_MODEL_INITIAL_EXEC to TLS_MODEL_LOCAL_EXEC
> by checking
>
> movq foo@gottpoff(%rip), %re
On Mon, Mar 5, 2012 at 9:25 AM, Uros Bizjak wrote:
> On Mon, Mar 5, 2012 at 6:03 PM, H.J. Lu wrote:
>
X86-64 linker optimizes TLS_MODEL_INITIAL_EXEC to TLS_MODEL_LOCAL_EXEC
by checking
movq foo@gottpoff(%rip), %reg
and
addq foo@gottpoff(%rip),
43 matches
Mail list logo
