Hi!
First: please be gentle: I don't speak RTL. ;-) And second: it's been
some time.
On 2013-12-04T16:06:48+, Tejas Belagod wrote:
> gcc/
> * rtlanal.c (set_noop_p): Return nonzero in case of redundant vec_select
> for overlapping register lanes.
This got committed to trunk in
On Wed, Dec 11, 2013 at 7:49 AM, Richard Sandiford
wrote:
> "H.J. Lu" writes:
>> On Wed, Dec 11, 2013 at 1:13 AM, Richard Sandiford
>> wrote:
>>> Richard Henderson writes:
On 12/10/2013 10:44 AM, Richard Sandiford wrote:
> Sorry, I don't understand. I never said it was invalid. I sai
H.J. Lu wrote:
On Wed, Dec 11, 2013 at 8:26 AM, Tejas Belagod wrote:
H.J. Lu wrote:
On Wed, Dec 11, 2013 at 7:49 AM, Richard Sandiford
wrote:
"H.J. Lu" writes:
On Wed, Dec 11, 2013 at 1:13 AM, Richard Sandiford
wrote:
Richard Henderson writes:
On 12/10/2013 10:44 AM, Richard Sandiford
On Wed, Dec 11, 2013 at 8:26 AM, Tejas Belagod wrote:
> H.J. Lu wrote:
>>
>> On Wed, Dec 11, 2013 at 7:49 AM, Richard Sandiford
>> wrote:
>>>
>>> "H.J. Lu" writes:
On Wed, Dec 11, 2013 at 1:13 AM, Richard Sandiford
wrote:
>
> Richard Henderson writes:
>>
>> On 12
H.J. Lu wrote:
On Wed, Dec 11, 2013 at 7:49 AM, Richard Sandiford
wrote:
"H.J. Lu" writes:
On Wed, Dec 11, 2013 at 1:13 AM, Richard Sandiford
wrote:
Richard Henderson writes:
On 12/10/2013 10:44 AM, Richard Sandiford wrote:
Sorry, I don't understand. I never said it was invalid. I said
On Wed, Dec 11, 2013 at 7:49 AM, Richard Sandiford
wrote:
> "H.J. Lu" writes:
>> On Wed, Dec 11, 2013 at 1:13 AM, Richard Sandiford
>> wrote:
>>> Richard Henderson writes:
On 12/10/2013 10:44 AM, Richard Sandiford wrote:
> Sorry, I don't understand. I never said it was invalid. I sai
"H.J. Lu" writes:
> On Wed, Dec 11, 2013 at 1:13 AM, Richard Sandiford
> wrote:
>> Richard Henderson writes:
>>> On 12/10/2013 10:44 AM, Richard Sandiford wrote:
Sorry, I don't understand. I never said it was invalid. I said
(subreg:SF (reg:V4SF X) 1) was invalid if (reg:V4SF X) repr
On Wed, Dec 11, 2013 at 1:13 AM, Richard Sandiford
wrote:
> Richard Henderson writes:
>> On 12/10/2013 10:44 AM, Richard Sandiford wrote:
>>> Sorry, I don't understand. I never said it was invalid. I said
>>> (subreg:SF (reg:V4SF X) 1) was invalid if (reg:V4SF X) represents
>>> a single registe
Richard Henderson writes:
> On 12/10/2013 10:44 AM, Richard Sandiford wrote:
>> Sorry, I don't understand. I never said it was invalid. I said
>> (subreg:SF (reg:V4SF X) 1) was invalid if (reg:V4SF X) represents
>> a single register. On a little-endian target, the offset cannot be
>> anything o
On Tue, Dec 10, 2013 at 2:33 PM, H.J. Lu wrote:
> On Tue, Dec 10, 2013 at 2:25 PM, Tejas Belagod
> wrote:
>> On 10 December 2013 21:51, H.J. Lu wrote:
>>> On Tue, Dec 10, 2013 at 1:09 PM, H.J. Lu wrote:
On Tue, Dec 10, 2013 at 12:39 PM, Richard Henderson
wrote:
> On 12/10/2013
On Tue, Dec 10, 2013 at 2:25 PM, Tejas Belagod wrote:
> On 10 December 2013 21:51, H.J. Lu wrote:
>> On Tue, Dec 10, 2013 at 1:09 PM, H.J. Lu wrote:
>>> On Tue, Dec 10, 2013 at 12:39 PM, Richard Henderson wrote:
On 12/10/2013 10:44 AM, Richard Sandiford wrote:
> Sorry, I don't understa
On 10 December 2013 21:51, H.J. Lu wrote:
> On Tue, Dec 10, 2013 at 1:09 PM, H.J. Lu wrote:
>> On Tue, Dec 10, 2013 at 12:39 PM, Richard Henderson wrote:
>>> On 12/10/2013 10:44 AM, Richard Sandiford wrote:
Sorry, I don't understand. I never said it was invalid. I said
(subreg:SF (re
On Tue, Dec 10, 2013 at 1:09 PM, H.J. Lu wrote:
> On Tue, Dec 10, 2013 at 12:39 PM, Richard Henderson wrote:
>> On 12/10/2013 10:44 AM, Richard Sandiford wrote:
>>> Sorry, I don't understand. I never said it was invalid. I said
>>> (subreg:SF (reg:V4SF X) 1) was invalid if (reg:V4SF X) represen
On Tue, Dec 10, 2013 at 12:39 PM, Richard Henderson wrote:
> On 12/10/2013 10:44 AM, Richard Sandiford wrote:
>> Sorry, I don't understand. I never said it was invalid. I said
>> (subreg:SF (reg:V4SF X) 1) was invalid if (reg:V4SF X) represents
>> a single register. On a little-endian target, t
On 12/10/2013 10:44 AM, Richard Sandiford wrote:
> Sorry, I don't understand. I never said it was invalid. I said
> (subreg:SF (reg:V4SF X) 1) was invalid if (reg:V4SF X) represents
> a single register. On a little-endian target, the offset cannot be
> anything other than 0 in that case.
>
> So
On Dec 10, 2013, at 2:12 PM, H.J. Lu wrote:
> On Tue, Dec 10, 2013 at 11:05 AM, Tejas Belagod wrote:
>> ...
>> So, if (subreg:DI (match_operand:V4SF 1 "register_operand" "x,x") 0) is a
>> valid subreg, why not allow it in CANNOT_CHANGE_MODE_CLASS (like in Kirill's
>> patch http://gcc.gnu.org/ml
On Tue, Dec 10, 2013 at 11:05 AM, Tejas Belagod wrote:
> H.J. Lu wrote:
>>
>> On Tue, Dec 10, 2013 at 9:26 AM, Tejas Belagod wrote:
>>>
>>> H.J. Lu wrote:
On Tue, Dec 10, 2013 at 9:04 AM, Kirill Yukhin
wrote:
>
> On 10 Dec 08:23, H.J. Lu wrote:
>>
>> What is wrong
H.J. Lu wrote:
On Tue, Dec 10, 2013 at 9:26 AM, Tejas Belagod wrote:
H.J. Lu wrote:
On Tue, Dec 10, 2013 at 9:04 AM, Kirill Yukhin
wrote:
On 10 Dec 08:23, H.J. Lu wrote:
What is wrong to pass the correct offset to
CANNOT_CHANGE_MODE_CLASS? Backends are free to
ignore it.
Yes, but as fas a
On Tue, Dec 10, 2013 at 10:44 AM, Richard Sandiford
wrote:
> "H.J. Lu" writes:
>> On Tue, Dec 10, 2013 at 10:26 AM, Richard Sandiford
>> wrote:
>>> "H.J. Lu" writes:
On Tue, Dec 10, 2013 at 9:57 AM, Richard Sandiford
wrote:
> "H.J. Lu" writes:
>> On Tue, Dec 10, 2013 at 8:05
"H.J. Lu" writes:
> On Tue, Dec 10, 2013 at 10:26 AM, Richard Sandiford
> wrote:
>> "H.J. Lu" writes:
>>> On Tue, Dec 10, 2013 at 9:57 AM, Richard Sandiford
>>> wrote:
"H.J. Lu" writes:
> On Tue, Dec 10, 2013 at 8:05 AM, Kirill Yukhin
> wrote:
>> On 09 Dec 14:08, H.J. Lu wrot
On Tue, Dec 10, 2013 at 10:26 AM, Richard Sandiford
wrote:
> "H.J. Lu" writes:
>> On Tue, Dec 10, 2013 at 9:57 AM, Richard Sandiford
>> wrote:
>>> "H.J. Lu" writes:
On Tue, Dec 10, 2013 at 8:05 AM, Kirill Yukhin
wrote:
> On 09 Dec 14:08, H.J. Lu wrote:
>>
>> There are no
"H.J. Lu" writes:
> On Tue, Dec 10, 2013 at 9:57 AM, Richard Sandiford
> wrote:
>> "H.J. Lu" writes:
>>> On Tue, Dec 10, 2013 at 8:05 AM, Kirill Yukhin
>>> wrote:
On 09 Dec 14:08, H.J. Lu wrote:
>
> There are no regressions on Linux/x86-64 with -m32 and -m64.
> Can you check if
On Tue, Dec 10, 2013 at 9:57 AM, Richard Sandiford
wrote:
> "H.J. Lu" writes:
>> On Tue, Dec 10, 2013 at 8:05 AM, Kirill Yukhin
>> wrote:
>>> On 09 Dec 14:08, H.J. Lu wrote:
There are no regressions on Linux/x86-64 with -m32 and -m64.
Can you check if it improves code quality on
"H.J. Lu" writes:
> On Tue, Dec 10, 2013 at 8:05 AM, Kirill Yukhin
> wrote:
>> On 09 Dec 14:08, H.J. Lu wrote:
>>>
>>> There are no regressions on Linux/x86-64 with -m32 and -m64.
>>> Can you check if it improves code quality on x886?
>>
>> As second thought. If Tejas and Richard are right and i
On Tue, Dec 10, 2013 at 9:26 AM, Tejas Belagod wrote:
> H.J. Lu wrote:
>>
>> On Tue, Dec 10, 2013 at 9:04 AM, Kirill Yukhin
>> wrote:
>>>
>>> On 10 Dec 08:23, H.J. Lu wrote:
What is wrong to pass the correct offset to
CANNOT_CHANGE_MODE_CLASS? Backends are free to
ignore it.
H.J. Lu wrote:
On Tue, Dec 10, 2013 at 9:04 AM, Kirill Yukhin wrote:
On 10 Dec 08:23, H.J. Lu wrote:
What is wrong to pass the correct offset to
CANNOT_CHANGE_MODE_CLASS? Backends are free to
ignore it.
Yes, but as fas as understand this hook as a predicate
saying if it not-safe to change mo
On Tue, Dec 10, 2013 at 9:04 AM, Kirill Yukhin wrote:
> On 10 Dec 08:23, H.J. Lu wrote:
>> What is wrong to pass the correct offset to
>> CANNOT_CHANGE_MODE_CLASS? Backends are free to
>> ignore it.
>
> Yes, but as fas as understand this hook as a predicate
> saying if it not-safe to change mode1
On Tue, Dec 10, 2013 at 9:09 AM, Kirill Yukhin wrote:
> On 10 Dec 09:02, H.J. Lu wrote:
>> On Tue, Dec 10, 2013 at 8:05 AM, Kirill Yukhin
>> wrote:
>> > On 09 Dec 14:08, H.J. Lu wrote:
>> > NOINLINE float
>> > foo32x2_le (float32x2_t x)
>> > {
>> > +#ifdef __i386__
>> > + __builtin_ia32_emms
On 10 Dec 09:02, H.J. Lu wrote:
> On Tue, Dec 10, 2013 at 8:05 AM, Kirill Yukhin
> wrote:
> > On 09 Dec 14:08, H.J. Lu wrote:
> > NOINLINE float
> > foo32x2_le (float32x2_t x)
> > {
> > +#ifdef __i386__
> > + __builtin_ia32_emms ();
> > +#endif
> >return bar (x[0]);
> > }
> You should ch
On 10 Dec 08:23, H.J. Lu wrote:
> What is wrong to pass the correct offset to
> CANNOT_CHANGE_MODE_CLASS? Backends are free to
> ignore it.
Yes, but as fas as understand this hook as a predicate
saying if it not-safe to change mode1 to mode2 for given
register class. I don't think that offsets sh
On Tue, Dec 10, 2013 at 8:05 AM, Kirill Yukhin wrote:
> On 09 Dec 14:08, H.J. Lu wrote:
>>
>> There are no regressions on Linux/x86-64 with -m32 and -m64.
>> Can you check if it improves code quality on x886?
>
> As second thought. If Tejas and Richard are right and it is simply incorrect
> to che
On Dec 10, 2013, at 9:50 AM, Kirill Yukhin wrote:
> Hello,
> On 09 Dec 14:08, H.J. Lu wrote:
>> There are no regressions on Linux/x86-64 with -m32 and -m64.
>> Can you check if it improves code quality on x886?
>
> That is exactly what I was talking about. However I wasn't sure
> that we can ch
On Tue, Dec 10, 2013 at 8:05 AM, Kirill Yukhin wrote:
> On 09 Dec 14:08, H.J. Lu wrote:
>>
>> There are no regressions on Linux/x86-64 with -m32 and -m64.
>> Can you check if it improves code quality on x886?
>
> As second thought. If Tejas and Richard are right and it is simply incorrect
> to che
On 09 Dec 14:08, H.J. Lu wrote:
>
> There are no regressions on Linux/x86-64 with -m32 and -m64.
> Can you check if it improves code quality on x886?
As second thought. If Tejas and Richard are right and it is simply incorrect
to check any offsets in this hook, may be we can end up with patch in
Hello,
On 09 Dec 14:08, H.J. Lu wrote:
> There are no regressions on Linux/x86-64 with -m32 and -m64.
> Can you check if it improves code quality on x886?
That is exactly what I was talking about. However I wasn't sure
that we can change already defined (and used throughout ports)
target hook.
An
On Mon, Dec 9, 2013 at 5:48 AM, H.J. Lu wrote:
> On Mon, Dec 9, 2013 at 5:00 AM, H.J. Lu wrote:
>> On Mon, Dec 9, 2013 at 1:56 AM, Tejas Belagod wrote:
>>> Kirill Yukhin wrote:
Hello,
On 05 Dec 16:40, Kirill Yukhin wrote:
>
> On 05 Dec 05:30, H.J. Lu wrote:
>>
>>>
On Mon, Dec 9, 2013 at 5:00 AM, H.J. Lu wrote:
> On Mon, Dec 9, 2013 at 1:56 AM, Tejas Belagod wrote:
>> Kirill Yukhin wrote:
>>>
>>> Hello,
>>>
>>> On 05 Dec 16:40, Kirill Yukhin wrote:
On 05 Dec 05:30, H.J. Lu wrote:
>
> Kirill, can you take a look why it doesn't work for x86?
On Mon, Dec 9, 2013 at 1:56 AM, Tejas Belagod wrote:
> Kirill Yukhin wrote:
>>
>> Hello,
>>
>> On 05 Dec 16:40, Kirill Yukhin wrote:
>>>
>>> On 05 Dec 05:30, H.J. Lu wrote:
Kirill, can you take a look why it doesn't work for x86?
>>>
>>> Okay, I'll look at this.
>>
>>
>> I've looked at t
Tejas Belagod writes:
> Kirill Yukhin wrote:
>> Hello,
>>
>> On 05 Dec 16:40, Kirill Yukhin wrote:
>>> On 05 Dec 05:30, H.J. Lu wrote:
Kirill, can you take a look why it doesn't work for x86?
>>> Okay, I'll look at this.
>>
>> I've looked at this. It seems that `CANNOT_CHANGE_MODE_CLASS'
>>
Kirill Yukhin wrote:
Hello,
On 05 Dec 16:40, Kirill Yukhin wrote:
On 05 Dec 05:30, H.J. Lu wrote:
Kirill, can you take a look why it doesn't work for x86?
Okay, I'll look at this.
I've looked at this. It seems that `CANNOT_CHANGE_MODE_CLASS'
is too conservative for x86.
In rtlanal.c we hav
Hello,
On 05 Dec 16:40, Kirill Yukhin wrote:
> On 05 Dec 05:30, H.J. Lu wrote:
> > Kirill, can you take a look why it doesn't work for x86?
> Okay, I'll look at this.
I've looked at this. It seems that `CANNOT_CHANGE_MODE_CLASS'
is too conservative for x86.
In rtlanal.c we have `simplify_subreg_
On Fri, Dec 06, 2013 at 05:12:08PM +, Tejas Belagod wrote:
> 2013-12-06 Tejas Belagod
>
> testsuite/
> * gcc.dg/vect/vect-nop-move.c: Fix dg options.
Ok, thanks.
> --- a/gcc/testsuite/gcc.dg/vect/vect-nop-move.c
> +++ b/gcc/testsuite/gcc.dg/vect/vect-nop-move.c
> @@ -1,6 +1,6 @@
Jakub Jelinek wrote:
On Wed, Dec 04, 2013 at 08:14:43AM -0800, H.J. Lu wrote:
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/vect-nop-move.c
@@ -0,0 +1,64 @@
+/* { dg-do run } */
+/* { dg-require-effective-target vect_float } */
+/* { dg-options "-O3 -fdump-rtl-combine-details" } */
Please chan
Jakub Jelinek wrote:
On Wed, Dec 04, 2013 at 08:14:43AM -0800, H.J. Lu wrote:
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/vect-nop-move.c
@@ -0,0 +1,64 @@
+/* { dg-do run } */
+/* { dg-require-effective-target vect_float } */
+/* { dg-options "-O3 -fdump-rtl-combine-details" } */
Please chan
On Wed, Dec 04, 2013 at 08:14:43AM -0800, H.J. Lu wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/vect/vect-nop-move.c
> > @@ -0,0 +1,64 @@
> > +/* { dg-do run } */
> > +/* { dg-require-effective-target vect_float } */
> > +/* { dg-options "-O3 -fdump-rtl-combine-details" } */
Please chang
On 12/05/13 09:12, Tejas Belagod wrote:
Now that Kirill's looking at why this doesn't work for x86, could I
check this in without enabling vect-nop-move.c for targets (i?86-*-*
x86_64-*-*)? If not, I'm happy to wait.
Yea, that's fine with me.
jeff
Jeff Law wrote:
On 12/04/13 09:06, Tejas Belagod wrote:
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
The problem is that one reg rtx can span several hard registers.
E.g. (reg:V4SI 32) might represent one 64-bit register (no. 32),
but it mig
Hello,
On 05 Dec 05:30, H.J. Lu wrote:
> Kirill, can you take a look why it doesn't work for x86?
Okay, I'll look at this.
--
Thanks, K
On Thu, Dec 5, 2013 at 5:17 AM, Tejas Belagod wrote:
> H.J. Lu wrote:
>>
>> On Wed, Dec 4, 2013 at 9:29 AM, Jeff Law wrote:
>>>
>>> On 12/04/13 09:14, H.J. Lu wrote:
>>>
> +
> +/* { dg-final { scan-rtl-dump "deleting noop move" "combine" { target
> aarch64*-*-* } } } */
H.J. Lu wrote:
On Wed, Dec 4, 2013 at 9:29 AM, Jeff Law wrote:
On 12/04/13 09:14, H.J. Lu wrote:
+
+/* { dg-final { scan-rtl-dump "deleting noop move" "combine" { target
aarch64*-*-* } } } */
Any particular reason why it doesn't work for x86?
I don't think so. I'm pretty sure Tejas is foc
On 12/04/13 09:06, Tejas Belagod wrote:
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
The problem is that one reg rtx can span several hard registers.
E.g. (reg:V4SI 32) might represent one 64-bit register (no. 32),
but it might instead repres
Tejas Belagod writes:
> Richard Sandiford wrote:
>> Tejas Belagod writes:
>>> Richard Sandiford wrote:
Tejas Belagod writes:
>> The problem is that one reg rtx can span several hard registers.
>> E.g. (reg:V4SI 32) might represent one 64-bit register (no. 32),
>> but it might in
On Wed, Dec 4, 2013 at 9:29 AM, Jeff Law wrote:
> On 12/04/13 09:14, H.J. Lu wrote:
>
>>> +
>>> +/* { dg-final { scan-rtl-dump "deleting noop move" "combine" { target
>>> aarch64*-*-* } } } */
>>
>>
>> Any particular reason why it doesn't work for x86?
>
> I don't think so. I'm pretty sure Tejas
On 12/04/13 09:14, H.J. Lu wrote:
+
+/* { dg-final { scan-rtl-dump "deleting noop move" "combine" { target
aarch64*-*-* } } } */
Any particular reason why it doesn't work for x86?
I don't think so. I'm pretty sure Tejas is focused on ARM platforms for
the obvious reason.
jeff
On Wed, Dec 4, 2013 at 8:06 AM, Tejas Belagod wrote:
> Thanks Richard. Here is a revised patch. Sorry about the delay - I was
> investigating to make sure an LRA ICE I was seeing on aarch64 was unrelated
> to this patch. I've added a test case that I expect to pass for aarch64.
> I've also added t
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
The problem is that one reg rtx can span several hard registers.
E.g. (reg:V4SI 32) might represent one 64-bit register (no. 32),
but it might instead represent two 32-bit registers (nos. 32 and 33)
Tejas Belagod writes:
> Richard Sandiford wrote:
>> Tejas Belagod writes:
The problem is that one reg rtx can span several hard registers.
E.g. (reg:V4SI 32) might represent one 64-bit register (no. 32),
but it might instead represent two 32-bit registers (nos. 32 and 33).
Obv
Richard Sandiford wrote:
Tejas Belagod writes:
The problem is that one reg rtx can span several hard registers.
E.g. (reg:V4SI 32) might represent one 64-bit register (no. 32),
but it might instead represent two 32-bit registers (nos. 32 and 33).
Obviously the latter's not very likely for vecto
Tejas Belagod writes:
>> The problem is that one reg rtx can span several hard registers.
>> E.g. (reg:V4SI 32) might represent one 64-bit register (no. 32),
>> but it might instead represent two 32-bit registers (nos. 32 and 33).
>> Obviously the latter's not very likely for vectors this small,
>
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
+ /* This is big-endian-safe because the elements are kept in target
+ memory order. So, for eg.
Tejas Belagod writes:
> Richard Sandiford wrote:
>> Tejas Belagod writes:
>>> Richard Sandiford wrote:
Tejas Belagod writes:
> Richard Sandiford wrote:
>> Tejas Belagod writes:
>>> + /* This is big-endian-safe because the elements are kept in target
>>> + memory order. So
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
+ /* This is big-endian-safe because the elements are kept in target
+ memory order. So, for eg. PARALLEL element value of 2 is the same in
+
On Wed, 2013-11-06 at 17:34 +, Richard Sandiford wrote:
> Tejas Belagod writes:
> > Richard Sandiford wrote:
> >> Tejas Belagod writes:
> >>> Richard Sandiford wrote:
> Tejas Belagod writes:
> > + /* This is big-endian-safe because the elements are kept in target
> > + memo
Tejas Belagod writes:
> Richard Sandiford wrote:
>> Tejas Belagod writes:
>>> Richard Sandiford wrote:
Tejas Belagod writes:
> + /* This is big-endian-safe because the elements are kept in target
> + memory order. So, for eg. PARALLEL element value of 2 is the same
> in
>
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
+ /* This is big-endian-safe because the elements are kept in target
+ memory order. So, for eg. PARALLEL element value of 2 is the same in
+ either endian-ness. */
+ if (GET_CODE (src)
On Wed, 2013-11-06 at 10:42 -0600, Bill Schmidt wrote:
> On Wed, 2013-11-06 at 15:01 +0100, Richard Biener wrote:
> > On Wed, Nov 6, 2013 at 2:24 PM, Tejas Belagod wrote:
> > >
> > > Hi,
> > >
> > > The attached patch eliminates moves of the form
> > >
> > > set( (reg:DI n) vec_select:DI
On Wed, 2013-11-06 at 15:01 +0100, Richard Biener wrote:
> On Wed, Nov 6, 2013 at 2:24 PM, Tejas Belagod wrote:
> >
> > Hi,
> >
> > The attached patch eliminates moves of the form
> >
> > set( (reg:DI n) vec_select:DI ( (reg:V2DI n) (parallel [const 0]
> >
> > i.e. eliminates lower lan
Tejas Belagod writes:
> Richard Sandiford wrote:
>> Tejas Belagod writes:
>>> + /* This is big-endian-safe because the elements are kept in target
>>> + memory order. So, for eg. PARALLEL element value of 2 is the same in
>>> + either endian-ness. */
>>> + if (GET_CODE (src) == VEC_SE
Richard Sandiford wrote:
Tejas Belagod writes:
+ /* This is big-endian-safe because the elements are kept in target
+ memory order. So, for eg. PARALLEL element value of 2 is the same in
+ either endian-ness. */
+ if (GET_CODE (src) == VEC_SELECT
+ && REG_P (XEXP (src, 0)) && R
Tejas Belagod writes:
> + /* This is big-endian-safe because the elements are kept in target
> + memory order. So, for eg. PARALLEL element value of 2 is the same in
> + either endian-ness. */
> + if (GET_CODE (src) == VEC_SELECT
> + && REG_P (XEXP (src, 0)) && REG_P (dst)
> +
On Wed, Nov 6, 2013 at 2:24 PM, Tejas Belagod wrote:
>
> Hi,
>
> The attached patch eliminates moves of the form
>
> set( (reg:DI n) vec_select:DI ( (reg:V2DI n) (parallel [const 0]
>
> i.e. eliminates lower lane moves between src and dst where src and dst are
> the same register and t
Hi,
The attached patch eliminates moves of the form
set( (reg:DI n) vec_select:DI ( (reg:V2DI n) (parallel [const 0]
i.e. eliminates lower lane moves between src and dst where src and dst are the
same register and this causes rtl to instead use the destination register in the
req
72 matches
Mail list logo
