Il 29/05/2014 19:20, pins...@gmail.com ha scritto:
What is your Pmode?
Pmode is dimode while ptr_mode is simode. Pointers are zero extended when
converting between si and di modes.
As you noted, the fundamental difference between x32 and aarch64 is that
aarch64 will still use 64-bit access
> On May 29, 2014, at 10:09 AM, "H.J. Lu" wrote:
>
>> On Thu, May 29, 2014 at 9:23 AM, wrote:
>>
>>
On May 29, 2014, at 9:13 AM, "H.J. Lu" wrote:
> On Wed, May 28, 2014 at 9:52 PM, Andrew Pinski wrote:
>> On Wed, Jul 13, 2011 at 9:39 AM, H.J. Lu wrote:
>>> On Wed,
On Thu, May 29, 2014 at 9:23 AM, wrote:
>
>
>> On May 29, 2014, at 9:13 AM, "H.J. Lu" wrote:
>>
>>> On Wed, May 28, 2014 at 9:52 PM, Andrew Pinski wrote:
On Wed, Jul 13, 2011 at 9:39 AM, H.J. Lu wrote:
> On Wed, Jul 13, 2011 at 9:13 AM, Paolo Bonzini wrote:
>> On 07/11/2011 05:54
> On May 29, 2014, at 9:13 AM, "H.J. Lu" wrote:
>
>> On Wed, May 28, 2014 at 9:52 PM, Andrew Pinski wrote:
>>> On Wed, Jul 13, 2011 at 9:39 AM, H.J. Lu wrote:
On Wed, Jul 13, 2011 at 9:13 AM, Paolo Bonzini wrote:
> On 07/11/2011 05:54 PM, H.J. Lu wrote:
>
> The key is the
>
On Wed, May 28, 2014 at 9:52 PM, Andrew Pinski wrote:
> On Wed, Jul 13, 2011 at 9:39 AM, H.J. Lu wrote:
>> On Wed, Jul 13, 2011 at 9:13 AM, Paolo Bonzini wrote:
>>> On 07/11/2011 05:54 PM, H.J. Lu wrote:
The key is the
>
> XEXP (x, 1) == convert_memory_address_addr_space
On Wed, Jul 13, 2011 at 9:39 AM, H.J. Lu wrote:
> On Wed, Jul 13, 2011 at 9:13 AM, Paolo Bonzini wrote:
>> On 07/11/2011 05:54 PM, H.J. Lu wrote:
>>>
>>> The key is the
>>> >
>>> > XEXP (x, 1) == convert_memory_address_addr_space
>>> >(to_mode, XEXP (x, 1), as)
>>> >
>>> >
On Sat, Jul 30, 2011 at 00:32, H.J. Lu wrote:
> The whole approach doesn't work. The testcase at
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49721#c1
>
> shows GCC depends on transforming:
>
> (zero_extend:DI (plus:SI (FOO:SI) (const_int Y)))
>
> to
>
> (plus:DI (zero_extend:DI (FOO:SI)) (cons
On Thu, Jul 28, 2011 at 11:34 PM, Paolo Bonzini wrote:
> Ok, you removed ignore_address_wrap_around, so we're almost there.
>
> On 07/28/2011 07:59 PM, H.J. Lu wrote:
>>
>> @@ -712,7 +715,16 @@ convert_modes (enum machine_mode mode, enum
>> machine_mode oldmode, rtx x, int uns
>> if (GET_CODE (
On Thu, Jul 28, 2011 at 2:31 AM, Paolo Bonzini wrote:
> On 07/28/2011 11:30 AM, Uros Bizjak wrote:
>>
>> > convert_memory_address_addr_space has a special PLUS/MULT case for
>> > POINTERS_EXTEND_UNSIGNED< 0. ?It turns out that it is also needed
>> > for all Pmode != ptr_mode cases. ?OK for tru
On 07/29/2011 08:34 AM, Paolo Bonzini wrote:
+ temp = rtl_hooks.gen_lowpart_no_emit (mode, x);
This line is obviously spurious, sorry.
+ if (no_emit)
+ return rtl_hooks.gen_lowpart_no_emit (mode, x);
+ else
+return gen_lowpart (mode, x);
Paolo
Ok, you removed ignore_address_wrap_around, so we're almost there.
On 07/28/2011 07:59 PM, H.J. Lu wrote:
@@ -712,7 +715,16 @@ convert_modes (enum machine_mode mode, enum machine_mode
oldmode, rtx x, int uns
if (GET_CODE (x) == SUBREG&& SUBREG_PROMOTED_VAR_P (x)
&& GET_MODE_SIZE (
On Thu, Jul 28, 2011 at 7:59 PM, H.J. Lu wrote:
>>> > convert_memory_address_addr_space has a special PLUS/MULT case for
>>> > POINTERS_EXTEND_UNSIGNED< 0. ?It turns out that it is also needed
>>> > for all Pmode != ptr_mode cases. ?OK for trunk?
>>> > 2011-06-11 ?H.J. Lu ?
>>> >
>>> > ? ?
On 07/28/2011 11:30 AM, Uros Bizjak wrote:
> convert_memory_address_addr_space has a special PLUS/MULT case for
> POINTERS_EXTEND_UNSIGNED< 0. ?It turns out that it is also needed
> for all Pmode != ptr_mode cases. ?OK for trunk?
> 2011-06-11 ?H.J. Lu ?
>
> ? ? ? ?PR middle-end/47727
> ? ?
Hello!
> convert_memory_address_addr_space has a special PLUS/MULT case for
> POINTERS_EXTEND_UNSIGNED < 0. ?It turns out that it is also needed
> for all Pmode != ptr_mode cases. ?OK for trunk?
> 2011-06-11 ?H.J. Lu ?
>
> ? ? ? ?PR middle-end/47727
> ? ? ? ?* explow.c (convert_memory_address_add
On 07/28/2011 12:59 AM, H.J. Lu wrote:
> Regarding correctness: you're converting a SImode operation to DImode by
> "pushing in" the zero_extend operation. What makes you think that base +
> constant offset won't overflow in any case?
You have not answered this.
> And also: what are you
On Wed, Jul 27, 2011 at 1:25 PM, Paolo Bonzini wrote:
> On 07/27/2011 07:29 PM, H.J. Lu wrote:
>>
>> If IRNORE_ADDRESS_WRAP_AROUND is TRUE, we
>> + also permute the conversion and addition of a constant. It is used to
>> + optimize cases where overflow of base + constant offset won't happen
>
On 07/27/2011 07:29 PM, H.J. Lu wrote:
If IRNORE_ADDRESS_WRAP_AROUND is TRUE, we
+ also permute the conversion and addition of a constant. It is used to
+ optimize cases where overflow of base + constant offset won't happen or
+ its behavior is implementation-defined for a given target. *
On Mon, Jul 25, 2011 at 2:58 AM, Paolo Bonzini wrote:
> On 07/13/2011 07:48 PM, H.J. Lu wrote:
>>
>> Here is the patch. OK for trunk?
>
> Again, at least you should explain clearly _why_ you need
> ignore_address_wrap_around. You said elsewhere x32 should be first clean,
> then fast.
>
>> if (
On 07/13/2011 07:48 PM, H.J. Lu wrote:
Here is the patch. OK for trunk?
Again, at least you should explain clearly _why_ you need
ignore_address_wrap_around. You said elsewhere x32 should be first
clean, then fast.
if (GET_CODE (x) == SUBREG && SUBREG_PROMOTED_VAR_P (x)
&& GET_
On Wed, Jul 13, 2011 at 9:54 AM, Paolo Bonzini wrote:
Why? Certainly Y = 8 has 31-bit (or less) precision. So it has the same
representation in SImode and DImode, and the test above on XEXP (x, 1)
succeeds.
>>>
>>> And then we permute conversion and addition, which leads to the is
>>> Why? Certainly Y = 8 has 31-bit (or less) precision. So it has the same
>>> representation in SImode and DImode, and the test above on XEXP (x, 1)
>>> succeeds.
>>
>> And then we permute conversion and addition, which leads to the issue you
>> raised above. In another word, the current code
On Wed, Jul 13, 2011 at 18:39, H.J. Lu wrote:
>> Why? Certainly Y = 8 has 31-bit (or less) precision. So it has the same
>> representation in SImode and DImode, and the test above on XEXP (x, 1)
>> succeeds.
>
> And then we permute conversion and addition, which leads to the issue you
> raised
On Wed, Jul 13, 2011 at 9:13 AM, Paolo Bonzini wrote:
> On 07/11/2011 05:54 PM, H.J. Lu wrote:
>>
>> The key is the
>> >
>> > XEXP (x, 1) == convert_memory_address_addr_space
>> > (to_mode, XEXP (x, 1), as)
>> >
>> > test. It ensures basically that the constant has 31-bit
On 07/11/2011 05:54 PM, H.J. Lu wrote:
The key is the
>
> XEXP (x, 1) == convert_memory_address_addr_space
>(to_mode, XEXP (x, 1), as)
>
> test. It ensures basically that the constant has 31-bit precision, because
> otherwise the constant would change from e.g. (const_i
On Mon, Jul 11, 2011 at 9:55 AM, H.J. Lu wrote:
> On Mon, Jul 11, 2011 at 8:54 AM, H.J. Lu wrote:
>> On Mon, Jul 11, 2011 at 4:03 AM, Paolo Bonzini wrote:
>>> On 07/11/2011 02:04 AM, H.J. Lu wrote:
With my original change, I got
(const:DI (plus:DI (symbol_ref:DI ("iplane.157
On Mon, Jul 11, 2011 at 8:54 AM, H.J. Lu wrote:
> On Mon, Jul 11, 2011 at 4:03 AM, Paolo Bonzini wrote:
>> On 07/11/2011 02:04 AM, H.J. Lu wrote:
>>>
>>> With my original change, I got
>>>
>>> (const:DI (plus:DI (symbol_ref:DI ("iplane.1577") [flags 0x2]
>>> )
>>> (const_int -4 [0xff
On Mon, Jul 11, 2011 at 4:03 AM, Paolo Bonzini wrote:
> On 07/11/2011 02:04 AM, H.J. Lu wrote:
>>
>> With my original change, I got
>>
>> (const:DI (plus:DI (symbol_ref:DI ("iplane.1577") [flags 0x2]
>> )
>> (const_int -4 [0xfffc])))
>>
>> I think it is safe to permute the con
On 07/11/2011 02:04 AM, H.J. Lu wrote:
With my original change, I got
(const:DI (plus:DI (symbol_ref:DI ("iplane.1577") [flags 0x2]
)
(const_int -4 [0xfffc])))
I think it is safe to permute the conversion and addition operation
if one operand is a constant and we are zero-
On Sun, Jul 10, 2011 at 5:04 PM, H.J. Lu wrote:
> On Sun, Jul 10, 2011 at 4:51 PM, H.J. Lu wrote:
>> On Sun, Jul 10, 2011 at 2:04 PM, H.J. Lu wrote:
>>> On Sun, Jul 10, 2011 at 9:36 AM, Paolo Bonzini wrote:
On Sat, Jul 9, 2011 at 23:31, H.J. Lu wrote:
> On Sat, Jul 9, 2011 at 2:18 PM,
On Sun, Jul 10, 2011 at 4:51 PM, H.J. Lu wrote:
> On Sun, Jul 10, 2011 at 2:04 PM, H.J. Lu wrote:
>> On Sun, Jul 10, 2011 at 9:36 AM, Paolo Bonzini wrote:
>>> On Sat, Jul 9, 2011 at 23:31, H.J. Lu wrote:
On Sat, Jul 9, 2011 at 2:18 PM, Paolo Bonzini wrote:
> On 07/05/2011 04:27 PM, H.
On Sun, Jul 10, 2011 at 2:04 PM, H.J. Lu wrote:
> On Sun, Jul 10, 2011 at 9:36 AM, Paolo Bonzini wrote:
>> On Sat, Jul 9, 2011 at 23:31, H.J. Lu wrote:
>>> On Sat, Jul 9, 2011 at 2:18 PM, Paolo Bonzini wrote:
On 07/05/2011 04:27 PM, H.J. Lu wrote:
>>
>> diff --git a/gcc/explow.c b
On Sun, Jul 10, 2011 at 9:36 AM, Paolo Bonzini wrote:
> On Sat, Jul 9, 2011 at 23:31, H.J. Lu wrote:
>> On Sat, Jul 9, 2011 at 2:18 PM, Paolo Bonzini wrote:
>>> On 07/05/2011 04:27 PM, H.J. Lu wrote:
>
> diff --git a/gcc/explow.c b/gcc/explow.c
> index 7387dad..b343bf8 100644
>
On Sat, Jul 9, 2011 at 23:31, H.J. Lu wrote:
> On Sat, Jul 9, 2011 at 2:18 PM, Paolo Bonzini wrote:
>> On 07/05/2011 04:27 PM, H.J. Lu wrote:
diff --git a/gcc/explow.c b/gcc/explow.c
index 7387dad..b343bf8 100644
--- a/gcc/explow.c
+++ b/gcc/explow.c
@@ -383,18
On Sat, Jul 9, 2011 at 2:18 PM, Paolo Bonzini wrote:
> On 07/05/2011 04:27 PM, H.J. Lu wrote:
>>>
>>> diff --git a/gcc/explow.c b/gcc/explow.c
>>> index 7387dad..b343bf8 100644
>>> --- a/gcc/explow.c
>>> +++ b/gcc/explow.c
>>> @@ -383,18 +383,13 @@ convert_memory_address_addr_space (enum
>>>
On 07/05/2011 04:27 PM, H.J. Lu wrote:
diff --git a/gcc/explow.c b/gcc/explow.c
index 7387dad..b343bf8 100644
--- a/gcc/explow.c
+++ b/gcc/explow.c
@@ -383,18 +383,13 @@ convert_memory_address_addr_space (enum machine_mode
to_mode ATTRIBUTE_UNUSED,
case PLUS:
case MULT:
-
Hi Jeff,
Can you take a look at this?
Thanks.
H.J.
On Tue, Jul 5, 2011 at 7:27 AM, H.J. Lu wrote:
> Ping.
>
> On Sat, Jun 11, 2011 at 8:58 AM, H.J. Lu wrote:
>> Hi,
>>
>> convert_memory_address_addr_space has a special PLUS/MULT case for
>> POINTERS_EXTEND_UNSIGNED < 0. It turns out that it i
Ping.
On Sat, Jun 11, 2011 at 8:58 AM, H.J. Lu wrote:
> Hi,
>
> convert_memory_address_addr_space has a special PLUS/MULT case for
> POINTERS_EXTEND_UNSIGNED < 0. It turns out that it is also needed
> for all Pmode != ptr_mode cases. OK for trunk?
>
> Thanks.
>
>
> H.J.
> ---
> 2011-06-11 H.J.
Hi,
convert_memory_address_addr_space has a special PLUS/MULT case for
POINTERS_EXTEND_UNSIGNED < 0. It turns out that it is also needed
for all Pmode != ptr_mode cases. OK for trunk?
Thanks.
H.J.
---
2011-06-11 H.J. Lu
PR middle-end/47727
* explow.c (convert_memory_addres
38 matches
Mail list logo
