On Mon, Mar 5, 2012 at 9:11 AM, H.J. Lu wrote:
> On Sun, Mar 4, 2012 at 11:47 PM, Uros Bizjak wrote:
>> On Mon, Mar 5, 2012 at 4:53 AM, H.J. Lu wrote:
>>
>>> and compiler does generate the same output. i386.c also has
>>>
>>> xasm = "jmp\t%A0";
>>> xasm = "call\t%A0";
>>>
>>> for calls
On Tue, Mar 6, 2012 at 6:40 AM, H.J. Lu wrote:
>>> >> >> We are expecting address to be 0x1001 - 1 == 0x1000. But, what we get
>>> >> >> is 0x1000 + 0x, not 0x1000 since 0x67 address prefix only
>>> >> >> applies to
>>> >> >> base register to zero-extend 0x to 64bit.
>>> >> >
>>
On Mon, Mar 5, 2012 at 9:31 AM, Jakub Jelinek wrote:
> On Mon, Mar 05, 2012 at 09:26:20AM -0800, H.J. Lu wrote:
>> On Mon, Mar 5, 2012 at 9:20 AM, Jakub Jelinek wrote:
>> > On Mon, Mar 05, 2012 at 09:13:49AM -0800, H.J. Lu wrote:
>> >> >> We are expecting address to be 0x1001 - 1 == 0x1000. But,
On Mon, Mar 05, 2012 at 09:26:20AM -0800, H.J. Lu wrote:
> On Mon, Mar 5, 2012 at 9:20 AM, Jakub Jelinek wrote:
> > On Mon, Mar 05, 2012 at 09:13:49AM -0800, H.J. Lu wrote:
> >> >> We are expecting address to be 0x1001 - 1 == 0x1000. But, what we get
> >> >> is 0x1000 + 0x, not 0x1000 sin
On Mon, Mar 5, 2012 at 9:20 AM, Jakub Jelinek wrote:
> On Mon, Mar 05, 2012 at 09:13:49AM -0800, H.J. Lu wrote:
>> >> We are expecting address to be 0x1001 - 1 == 0x1000. But, what we get
>> >> is 0x1000 + 0x, not 0x1000 since 0x67 address prefix only applies
>> >> to
>> >> base register
On Mon, Mar 05, 2012 at 09:13:49AM -0800, H.J. Lu wrote:
> >> We are expecting address to be 0x1001 - 1 == 0x1000. But, what we get
> >> is 0x1000 + 0x, not 0x1000 since 0x67 address prefix only applies
> >> to
> >> base register to zero-extend 0x to 64bit.
> >
> > I would call th
On Mon, Mar 5, 2012 at 12:24 AM, Uros Bizjak wrote:
> On Mon, Mar 5, 2012 at 9:01 AM, Uros Bizjak wrote:
>
@@ -11388,6 +11400,11 @@ ix86_decompose_address (rtx addr, struct
ix86_address *out)
else
disp = addr; /* displacement */
+ /* Sinc
On Mon, Mar 5, 2012 at 12:01 AM, Uros Bizjak wrote:
> On Sun, Mar 4, 2012 at 11:01 PM, H.J. Lu wrote:
>
>>> @@ -11388,6 +11400,11 @@ ix86_decompose_address (rtx addr, struct
>>> ix86_address *out)
>>> else
>>> disp = addr; /* displacement */
>>>
>>> + /* Since address
On Sun, Mar 4, 2012 at 11:47 PM, Uros Bizjak wrote:
> On Mon, Mar 5, 2012 at 4:53 AM, H.J. Lu wrote:
>
>> and compiler does generate the same output. i386.c also has
>>
>> xasm = "jmp\t%A0";
>> xasm = "call\t%A0";
>>
>> for calls. There are no separate indirect call patterns. For x32,
On Mon, Mar 5, 2012 at 9:01 AM, Uros Bizjak wrote:
>>> @@ -11388,6 +11400,11 @@ ix86_decompose_address (rtx addr, struct
>>> ix86_address *out)
>>> else
>>> disp = addr; /* displacement */
>>>
>>> + /* Since address override works only on the (reg) part in fs:(reg),
>
On Sun, Mar 4, 2012 at 11:01 PM, H.J. Lu wrote:
>> @@ -11388,6 +11400,11 @@ ix86_decompose_address (rtx addr, struct
>> ix86_address *out)
>> else
>> disp = addr; /* displacement */
>>
>> + /* Since address override works only on the (reg) part in fs:(reg),
>> + w
On Mon, Mar 5, 2012 at 4:53 AM, H.J. Lu wrote:
> and compiler does generate the same output. i386.c also has
>
> xasm = "jmp\t%A0";
> xasm = "call\t%A0";
>
> for calls. There are no separate indirect call patterns. For x32,
> only indirect register calls have to be in DImode. The dir
"H.J. Lu" writes:
>> @@ -11060,8 +11072,8 @@ ix86_expand_split_stack_prologue (void)
>> {
>> rtx rax;
>>
>> - rax = gen_rtx_REG (Pmode, AX_REG);
>> - emit_move_insn (rax, reg10);
>> + rax = gen_rtx_REG (word_mode, AX_REG);
>> + emit_move_insn (rax,
On Sun, Mar 4, 2012 at 2:40 PM, Uros Bizjak wrote:
> On Sun, Mar 4, 2012 at 11:01 PM, H.J. Lu wrote:
>
>>> @@ -13637,7 +13665,8 @@ ix86_print_operand (FILE *file, rtx x, int code)
>>> gcc_unreachable ();
>>> }
>>>
>>> - ix86_print_operand (file, x, 0);
>>> +
On Sun, Mar 4, 2012 at 11:01 PM, H.J. Lu wrote:
>> @@ -13637,7 +13665,8 @@ ix86_print_operand (FILE *file, rtx x, int code)
>> gcc_unreachable ();
>> }
>>
>> - ix86_print_operand (file, x, 0);
>> + ix86_print_operand (file, x,
>> +
On Sun, Mar 4, 2012 at 12:09 PM, Uros Bizjak wrote:
> On Sat, Nov 12, 2011 at 3:19 AM, H.J. Lu wrote:
>
>> The current x32 implementation uses LEAs to convert 32bit address to
>> 64bit. However, we can use addr32 prefix to use 32bit address directly.
>> It improves performance by 5% in SPEC CPU
On Sat, Nov 12, 2011 at 3:19 AM, H.J. Lu wrote:
> The current x32 implementation uses LEAs to convert 32bit address to
> 64bit. However, we can use addr32 prefix to use 32bit address directly.
> It improves performance by 5% in SPEC CPU 2K/2006. All changes are done
> in x86 backend, except for
On Sat, Nov 12, 2011 at 9:32 AM, Uros Bizjak wrote:
> On Sat, Nov 12, 2011 at 3:19 AM, H.J. Lu wrote:
>
>> The current x32 implementation uses LEAs to convert 32bit address to
>> 64bit. However, we can use addr32 prefix to use 32bit address directly.
>> It improves performance by 5% in SPEC CPU
On Sat, Nov 12, 2011 at 3:19 AM, H.J. Lu wrote:
> The current x32 implementation uses LEAs to convert 32bit address to
> 64bit. However, we can use addr32 prefix to use 32bit address directly.
> It improves performance by 5% in SPEC CPU 2K/2006. All changes are done
> in x86 backend, except for
19 matches
Mail list logo
