* vectorization, scheduling and aliasing
@ 2010-04-14 8:40 roy rosen
2010-04-14 11:07 ` Richard Guenther
0 siblings, 1 reply; 9+ messages in thread
From: roy rosen @ 2010-04-14 8:40 UTC (permalink / raw)
To: gcc
Hi All,
I have implemented some vectorization features in my gcc port.
In the generated code for this function I can see a scheduling problem:
int xxx(int* __restrict__ a, int* __restrict__ b)
{
int __restrict__ i;
for (i = 0; i < 8; i++)
{
a[i] = b[i];
}
return 0;
}
from asmcons:
(insn 17 14 18 3 a.c:15 (set (reg:V4HI 105)
(mem:V4HI (reg/v/f:SI 100 [ b ]) [2 S8 A64])) 115 {*movv4hi_load} (nil))
(insn 18 17 19 3 a.c:15 (set (mem:V4HI (reg/v/f:SI 99 [ a ]) [2 S8 A64])
(reg:V4HI 105)) 116 {*movv4hi_store} (expr_list:REG_DEAD (reg:V4HI 105)
(nil)))
(insn 19 18 20 3 a.c:15 (set (reg:V4HI 106)
(mem:V4HI (plus:SI (reg/v/f:SI 100 [ b ])
(const_int 8 [0x8])) [2 S8 A64])) 115 {*movv4hi_load}
(expr_list:REG_DEAD (reg/v/f:SI 100 [ b ])
(nil)))
(insn 20 19 58 3 a.c:15 (set (mem:V4HI (plus:SI (reg/v/f:SI 99 [ a ])
(const_int 8 [0x8])) [2 S8 A64])
(reg:V4HI 106)) 116 {*movv4hi_store} (expr_list:REG_DEAD (reg:V4HI 106)
(expr_list:REG_DEAD (reg/v/f:SI 99 [ a ])
(nil))))
from sched1 - dependecies list:
--- Region Dependences --- b 3 bb 0
;; insn code bb dep prio cost reservation
;; ---- ---- -- --- ---- ---- -----------
;; 17 115 3 0 4 1 (2_slots+lsu) : 58 20 18
;; 18 116 3 1 3 1 (2_slots+lsu) : 58 19
;; 19 115 3 1 2 1 (2_slots+lsu) : 58 20
;; 20 116 3 2 1 1 (2_slots+lsu) : 58
;; 58 101 3 4 1 1 (3_slots+pcu) :
As you can see, insn 19 is dependant on 18.
I think that this should not happen since the arrays has __restrict__.
It might have something to do with aliasing.
Are you aware of any kind of problems regarding aliasing and vectors?
Can you think of anything else that might be wrong in my code that
leads gcc to think that there is a dependency between insn 18 and 19?
Thanks, Roy.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: vectorization, scheduling and aliasing
2010-04-14 8:40 vectorization, scheduling and aliasing roy rosen
@ 2010-04-14 11:07 ` Richard Guenther
2010-04-22 16:22 ` roy rosen
0 siblings, 1 reply; 9+ messages in thread
From: Richard Guenther @ 2010-04-14 11:07 UTC (permalink / raw)
To: roy rosen; +Cc: gcc
On Wed, Apr 14, 2010 at 8:48 AM, roy rosen <roy.1rosen@gmail.com> wrote:
> Hi All,
>
> I have implemented some vectorization features in my gcc port.
>
> In the generated code for this function I can see a scheduling problem:
>
> int xxx(int* __restrict__ a, int* __restrict__ b)
> {
> int __restrict__ i;
> for (i = 0; i < 8; i++)
> {
> a[i] = b[i];
> }
> return 0;
> }
>
> from asmcons:
>
> (insn 17 14 18 3 a.c:15 (set (reg:V4HI 105)
> (mem:V4HI (reg/v/f:SI 100 [ b ]) [2 S8 A64])) 115 {*movv4hi_load} (nil))
>
> (insn 18 17 19 3 a.c:15 (set (mem:V4HI (reg/v/f:SI 99 [ a ]) [2 S8 A64])
> (reg:V4HI 105)) 116 {*movv4hi_store} (expr_list:REG_DEAD (reg:V4HI 105)
> (nil)))
>
> (insn 19 18 20 3 a.c:15 (set (reg:V4HI 106)
> (mem:V4HI (plus:SI (reg/v/f:SI 100 [ b ])
> (const_int 8 [0x8])) [2 S8 A64])) 115 {*movv4hi_load}
> (expr_list:REG_DEAD (reg/v/f:SI 100 [ b ])
> (nil)))
>
> (insn 20 19 58 3 a.c:15 (set (mem:V4HI (plus:SI (reg/v/f:SI 99 [ a ])
> (const_int 8 [0x8])) [2 S8 A64])
> (reg:V4HI 106)) 116 {*movv4hi_store} (expr_list:REG_DEAD (reg:V4HI 106)
> (expr_list:REG_DEAD (reg/v/f:SI 99 [ a ])
> (nil))))
>
> from sched1 - dependecies list:
> --- Region Dependences --- b 3 bb 0
> ;; insn code bb dep prio cost reservation
> ;; ---- ---- -- --- ---- ---- -----------
> ;; 17 115 3 0 4 1 (2_slots+lsu) : 58 20 18
> ;; 18 116 3 1 3 1 (2_slots+lsu) : 58 19
> ;; 19 115 3 1 2 1 (2_slots+lsu) : 58 20
> ;; 20 116 3 2 1 1 (2_slots+lsu) : 58
> ;; 58 101 3 4 1 1 (3_slots+pcu) :
>
> As you can see, insn 19 is dependant on 18.
> I think that this should not happen since the arrays has __restrict__.
> It might have something to do with aliasing.
>
> Are you aware of any kind of problems regarding aliasing and vectors?
> Can you think of anything else that might be wrong in my code that
> leads gcc to think that there is a dependency between insn 18 and 19?
It completely depends on the GCC version you are using. The
MEM_EXPRs suggest that it is maybe 4.4 or 4.5 based? Because
they are not existant. Try recent trunk which should work fine.
Richard.
> Thanks, Roy.
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: vectorization, scheduling and aliasing
2010-04-14 11:07 ` Richard Guenther
@ 2010-04-22 16:22 ` roy rosen
2010-04-23 12:12 ` Richard Guenther
0 siblings, 1 reply; 9+ messages in thread
From: roy rosen @ 2010-04-22 16:22 UTC (permalink / raw)
To: Richard Guenther; +Cc: gcc
Hi Richard,
2010/4/14, Richard Guenther <richard.guenther@gmail.com>:
> On Wed, Apr 14, 2010 at 8:48 AM, roy rosen <roy.1rosen@gmail.com> wrote:
> > Hi All,
> >
> > I have implemented some vectorization features in my gcc port.
> >
> > In the generated code for this function I can see a scheduling problem:
> >
> > int xxx(int* __restrict__ a, int* __restrict__ b)
> > {
> > int __restrict__ i;
> > for (i = 0; i < 8; i++)
> > {
> > a[i] = b[i];
> > }
> > return 0;
> > }
> >
> > from asmcons:
> >
> > (insn 17 14 18 3 a.c:15 (set (reg:V4HI 105)
> > (mem:V4HI (reg/v/f:SI 100 [ b ]) [2 S8 A64])) 115 {*movv4hi_load} (nil))
> >
> > (insn 18 17 19 3 a.c:15 (set (mem:V4HI (reg/v/f:SI 99 [ a ]) [2 S8 A64])
> > (reg:V4HI 105)) 116 {*movv4hi_store} (expr_list:REG_DEAD (reg:V4HI 105)
> > (nil)))
> >
> > (insn 19 18 20 3 a.c:15 (set (reg:V4HI 106)
> > (mem:V4HI (plus:SI (reg/v/f:SI 100 [ b ])
> > (const_int 8 [0x8])) [2 S8 A64])) 115 {*movv4hi_load}
> > (expr_list:REG_DEAD (reg/v/f:SI 100 [ b ])
> > (nil)))
> >
> > (insn 20 19 58 3 a.c:15 (set (mem:V4HI (plus:SI (reg/v/f:SI 99 [ a ])
> > (const_int 8 [0x8])) [2 S8 A64])
> > (reg:V4HI 106)) 116 {*movv4hi_store} (expr_list:REG_DEAD (reg:V4HI 106)
> > (expr_list:REG_DEAD (reg/v/f:SI 99 [ a ])
> > (nil))))
> >
> > from sched1 - dependecies list:
> > --- Region Dependences --- b 3 bb 0
> > ;; insn code bb dep prio cost reservation
> > ;; ---- ---- -- --- ---- ---- -----------
> > ;; 17 115 3 0 4 1 (2_slots+lsu) : 58 20 18
> > ;; 18 116 3 1 3 1 (2_slots+lsu) : 58 19
> > ;; 19 115 3 1 2 1 (2_slots+lsu) : 58 20
> > ;; 20 116 3 2 1 1 (2_slots+lsu) : 58
> > ;; 58 101 3 4 1 1 (3_slots+pcu) :
> >
> > As you can see, insn 19 is dependant on 18.
> > I think that this should not happen since the arrays has __restrict__.
> > It might have something to do with aliasing.
> >
> > Are you aware of any kind of problems regarding aliasing and vectors?
> > Can you think of anything else that might be wrong in my code that
> > leads gcc to think that there is a dependency between insn 18 and 19?
>
> It completely depends on the GCC version you are using. The
> MEM_EXPRs suggest that it is maybe 4.4 or 4.5 based? Because
> they are not existant. Try recent trunk which should work fine.
>
> Richard.
>
> > Thanks, Roy.
> >
>
I have taken 4.5.0 and I still get the same problem.
Do you have any ideas? Shouldn't the restrict tell the compiler that
there is no dependency between these insns?
Thanks, Roy.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: vectorization, scheduling and aliasing
2010-04-22 16:22 ` roy rosen
@ 2010-04-23 12:12 ` Richard Guenther
2010-04-26 7:57 ` roy rosen
0 siblings, 1 reply; 9+ messages in thread
From: Richard Guenther @ 2010-04-23 12:12 UTC (permalink / raw)
To: roy rosen; +Cc: gcc
On Thu, Apr 22, 2010 at 6:04 PM, roy rosen <roy.1rosen@gmail.com> wrote:
> Hi Richard,
>
> 2010/4/14, Richard Guenther <richard.guenther@gmail.com>:
>> On Wed, Apr 14, 2010 at 8:48 AM, roy rosen <roy.1rosen@gmail.com> wrote:
>> > Hi All,
>> >
>> > I have implemented some vectorization features in my gcc port.
>> >
>> > In the generated code for this function I can see a scheduling problem:
>> >
>> > int xxx(int* __restrict__ a, int* __restrict__ b)
>> > {
>> > int __restrict__ i;
>> > for (i = 0; i < 8; i++)
>> > {
>> > a[i] = b[i];
>> > }
>> > return 0;
>> > }
>> >
>> > from asmcons:
>> >
>> > (insn 17 14 18 3 a.c:15 (set (reg:V4HI 105)
>> > (mem:V4HI (reg/v/f:SI 100 [ b ]) [2 S8 A64])) 115 {*movv4hi_load} (nil))
>> >
>> > (insn 18 17 19 3 a.c:15 (set (mem:V4HI (reg/v/f:SI 99 [ a ]) [2 S8 A64])
>> > (reg:V4HI 105)) 116 {*movv4hi_store} (expr_list:REG_DEAD (reg:V4HI 105)
>> > (nil)))
>> >
>> > (insn 19 18 20 3 a.c:15 (set (reg:V4HI 106)
>> > (mem:V4HI (plus:SI (reg/v/f:SI 100 [ b ])
>> > (const_int 8 [0x8])) [2 S8 A64])) 115 {*movv4hi_load}
>> > (expr_list:REG_DEAD (reg/v/f:SI 100 [ b ])
>> > (nil)))
>> >
>> > (insn 20 19 58 3 a.c:15 (set (mem:V4HI (plus:SI (reg/v/f:SI 99 [ a ])
>> > (const_int 8 [0x8])) [2 S8 A64])
>> > (reg:V4HI 106)) 116 {*movv4hi_store} (expr_list:REG_DEAD (reg:V4HI 106)
>> > (expr_list:REG_DEAD (reg/v/f:SI 99 [ a ])
>> > (nil))))
>> >
>> > from sched1 - dependecies list:
>> > --- Region Dependences --- b 3 bb 0
>> > ;; insn code bb dep prio cost reservation
>> > ;; ---- ---- -- --- ---- ---- -----------
>> > ;; 17 115 3 0 4 1 (2_slots+lsu) : 58 20 18
>> > ;; 18 116 3 1 3 1 (2_slots+lsu) : 58 19
>> > ;; 19 115 3 1 2 1 (2_slots+lsu) : 58 20
>> > ;; 20 116 3 2 1 1 (2_slots+lsu) : 58
>> > ;; 58 101 3 4 1 1 (3_slots+pcu) :
>> >
>> > As you can see, insn 19 is dependant on 18.
>> > I think that this should not happen since the arrays has __restrict__.
>> > It might have something to do with aliasing.
>> >
>> > Are you aware of any kind of problems regarding aliasing and vectors?
>> > Can you think of anything else that might be wrong in my code that
>> > leads gcc to think that there is a dependency between insn 18 and 19?
>>
>> It completely depends on the GCC version you are using. The
>> MEM_EXPRs suggest that it is maybe 4.4 or 4.5 based? Because
>> they are not existant. Try recent trunk which should work fine.
>>
>> Richard.
>>
>> > Thanks, Roy.
>> >
>>
>
> I have taken 4.5.0 and I still get the same problem.
> Do you have any ideas? Shouldn't the restrict tell the compiler that
> there is no dependency between these insns?
It doesn't work for 4.5.0 due to PR42617.
Richard.
> Thanks, Roy.
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: vectorization, scheduling and aliasing
2010-04-23 12:12 ` Richard Guenther
@ 2010-04-26 7:57 ` roy rosen
2010-04-26 11:24 ` Richard Guenther
0 siblings, 1 reply; 9+ messages in thread
From: roy rosen @ 2010-04-26 7:57 UTC (permalink / raw)
To: Richard Guenther; +Cc: gcc
Hi Richard,
2010/4/23, Richard Guenther <richard.guenther@gmail.com>:
> On Thu, Apr 22, 2010 at 6:04 PM, roy rosen <roy.1rosen@gmail.com> wrote:
> > Hi Richard,
> >
> > 2010/4/14, Richard Guenther <richard.guenther@gmail.com>:
> >> On Wed, Apr 14, 2010 at 8:48 AM, roy rosen <roy.1rosen@gmail.com> wrote:
> >> > Hi All,
> >> >
> >> > I have implemented some vectorization features in my gcc port.
> >> >
> >> > In the generated code for this function I can see a scheduling problem:
> >> >
> >> > int xxx(int* __restrict__ a, int* __restrict__ b)
> >> > {
> >> > int __restrict__ i;
> >> > for (i = 0; i < 8; i++)
> >> > {
> >> > a[i] = b[i];
> >> > }
> >> > return 0;
> >> > }
> >> >
> >> > from asmcons:
> >> >
> >> > (insn 17 14 18 3 a.c:15 (set (reg:V4HI 105)
> >> > (mem:V4HI (reg/v/f:SI 100 [ b ]) [2 S8 A64])) 115 {*movv4hi_load} (nil))
> >> >
> >> > (insn 18 17 19 3 a.c:15 (set (mem:V4HI (reg/v/f:SI 99 [ a ]) [2 S8 A64])
> >> > (reg:V4HI 105)) 116 {*movv4hi_store} (expr_list:REG_DEAD (reg:V4HI 105)
> >> > (nil)))
> >> >
> >> > (insn 19 18 20 3 a.c:15 (set (reg:V4HI 106)
> >> > (mem:V4HI (plus:SI (reg/v/f:SI 100 [ b ])
> >> > (const_int 8 [0x8])) [2 S8 A64])) 115 {*movv4hi_load}
> >> > (expr_list:REG_DEAD (reg/v/f:SI 100 [ b ])
> >> > (nil)))
> >> >
> >> > (insn 20 19 58 3 a.c:15 (set (mem:V4HI (plus:SI (reg/v/f:SI 99 [ a ])
> >> > (const_int 8 [0x8])) [2 S8 A64])
> >> > (reg:V4HI 106)) 116 {*movv4hi_store} (expr_list:REG_DEAD (reg:V4HI 106)
> >> > (expr_list:REG_DEAD (reg/v/f:SI 99 [ a ])
> >> > (nil))))
> >> >
> >> > from sched1 - dependecies list:
> >> > --- Region Dependences --- b 3 bb 0
> >> > ;; insn code bb dep prio cost reservation
> >> > ;; ---- ---- -- --- ---- ---- -----------
> >> > ;; 17 115 3 0 4 1 (2_slots+lsu) : 58 20 18
> >> > ;; 18 116 3 1 3 1 (2_slots+lsu) : 58 19
> >> > ;; 19 115 3 1 2 1 (2_slots+lsu) : 58 20
> >> > ;; 20 116 3 2 1 1 (2_slots+lsu) : 58
> >> > ;; 58 101 3 4 1 1 (3_slots+pcu) :
> >> >
> >> > As you can see, insn 19 is dependant on 18.
> >> > I think that this should not happen since the arrays has __restrict__.
> >> > It might have something to do with aliasing.
> >> >
> >> > Are you aware of any kind of problems regarding aliasing and vectors?
> >> > Can you think of anything else that might be wrong in my code that
> >> > leads gcc to think that there is a dependency between insn 18 and 19?
> >>
> >> It completely depends on the GCC version you are using. The
> >> MEM_EXPRs suggest that it is maybe 4.4 or 4.5 based? Because
> >> they are not existant. Try recent trunk which should work fine.
> >>
> >> Richard.
> >>
> >> > Thanks, Roy.
> >> >
> >>
> >
> > I have taken 4.5.0 and I still get the same problem.
> > Do you have any ideas? Shouldn't the restrict tell the compiler that
> > there is no dependency between these insns?
>
> It doesn't work for 4.5.0 due to PR42617.
>
> Richard.
>
> > Thanks, Roy.
> >
>
I took snapshot 4.6-20100424 (is this version ok?) and the problem
still occurs when I am looking at the vectorized version of the code.
It seems ok in the nonvectorized version.
What might be the problem?
Thanks, Roy.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: vectorization, scheduling and aliasing
2010-04-26 7:57 ` roy rosen
@ 2010-04-26 11:24 ` Richard Guenther
2010-04-26 13:51 ` roy rosen
0 siblings, 1 reply; 9+ messages in thread
From: Richard Guenther @ 2010-04-26 11:24 UTC (permalink / raw)
To: roy rosen; +Cc: gcc
On Mon, Apr 26, 2010 at 9:43 AM, roy rosen <roy.1rosen@gmail.com> wrote:
> Hi Richard,
>
> 2010/4/23, Richard Guenther <richard.guenther@gmail.com>:
>> On Thu, Apr 22, 2010 at 6:04 PM, roy rosen <roy.1rosen@gmail.com> wrote:
>> > Hi Richard,
>> >
>> > 2010/4/14, Richard Guenther <richard.guenther@gmail.com>:
>> >> On Wed, Apr 14, 2010 at 8:48 AM, roy rosen <roy.1rosen@gmail.com> wrote:
>> >> > Hi All,
>> >> >
>> >> > I have implemented some vectorization features in my gcc port.
>> >> >
>> >> > In the generated code for this function I can see a scheduling problem:
>> >> >
>> >> > int xxx(int* __restrict__ a, int* __restrict__ b)
>> >> > {
>> >> > int __restrict__ i;
>> >> > for (i = 0; i < 8; i++)
>> >> > {
>> >> > a[i] = b[i];
>> >> > }
>> >> > return 0;
>> >> > }
>> >> >
>> >> > from asmcons:
>> >> >
>> >> > (insn 17 14 18 3 a.c:15 (set (reg:V4HI 105)
>> >> > (mem:V4HI (reg/v/f:SI 100 [ b ]) [2 S8 A64])) 115 {*movv4hi_load} (nil))
>> >> >
>> >> > (insn 18 17 19 3 a.c:15 (set (mem:V4HI (reg/v/f:SI 99 [ a ]) [2 S8 A64])
>> >> > (reg:V4HI 105)) 116 {*movv4hi_store} (expr_list:REG_DEAD (reg:V4HI 105)
>> >> > (nil)))
>> >> >
>> >> > (insn 19 18 20 3 a.c:15 (set (reg:V4HI 106)
>> >> > (mem:V4HI (plus:SI (reg/v/f:SI 100 [ b ])
>> >> > (const_int 8 [0x8])) [2 S8 A64])) 115 {*movv4hi_load}
>> >> > (expr_list:REG_DEAD (reg/v/f:SI 100 [ b ])
>> >> > (nil)))
>> >> >
>> >> > (insn 20 19 58 3 a.c:15 (set (mem:V4HI (plus:SI (reg/v/f:SI 99 [ a ])
>> >> > (const_int 8 [0x8])) [2 S8 A64])
>> >> > (reg:V4HI 106)) 116 {*movv4hi_store} (expr_list:REG_DEAD (reg:V4HI 106)
>> >> > (expr_list:REG_DEAD (reg/v/f:SI 99 [ a ])
>> >> > (nil))))
>> >> >
>> >> > from sched1 - dependecies list:
>> >> > --- Region Dependences --- b 3 bb 0
>> >> > ;; insn code bb dep prio cost reservation
>> >> > ;; ---- ---- -- --- ---- ---- -----------
>> >> > ;; 17 115 3 0 4 1 (2_slots+lsu) : 58 20 18
>> >> > ;; 18 116 3 1 3 1 (2_slots+lsu) : 58 19
>> >> > ;; 19 115 3 1 2 1 (2_slots+lsu) : 58 20
>> >> > ;; 20 116 3 2 1 1 (2_slots+lsu) : 58
>> >> > ;; 58 101 3 4 1 1 (3_slots+pcu) :
>> >> >
>> >> > As you can see, insn 19 is dependant on 18.
>> >> > I think that this should not happen since the arrays has __restrict__.
>> >> > It might have something to do with aliasing.
>> >> >
>> >> > Are you aware of any kind of problems regarding aliasing and vectors?
>> >> > Can you think of anything else that might be wrong in my code that
>> >> > leads gcc to think that there is a dependency between insn 18 and 19?
>> >>
>> >> It completely depends on the GCC version you are using. The
>> >> MEM_EXPRs suggest that it is maybe 4.4 or 4.5 based? Because
>> >> they are not existant. Try recent trunk which should work fine.
>> >>
>> >> Richard.
>> >>
>> >> > Thanks, Roy.
>> >> >
>> >>
>> >
>> > I have taken 4.5.0 and I still get the same problem.
>> > Do you have any ideas? Shouldn't the restrict tell the compiler that
>> > there is no dependency between these insns?
>>
>> It doesn't work for 4.5.0 due to PR42617.
>>
>> Richard.
>>
>> > Thanks, Roy.
>> >
>>
>
> I took snapshot 4.6-20100424 (is this version ok?) and the problem
> still occurs when I am looking at the vectorized version of the code.
> It seems ok in the nonvectorized version.
>
> What might be the problem?
Look at the -fdump-tree-optimized-alias dump, likely the defs
of the pointer SSA names that are used in the loads/stores
have their alias information dropped. Or the vectorizer emits
ALIGN_INDIRECT_REFs on your target which we still drop.
Richard.
> Thanks, Roy.
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: vectorization, scheduling and aliasing
2010-04-26 11:24 ` Richard Guenther
@ 2010-04-26 13:51 ` roy rosen
2010-04-26 14:34 ` Richard Guenther
0 siblings, 1 reply; 9+ messages in thread
From: roy rosen @ 2010-04-26 13:51 UTC (permalink / raw)
To: Richard Guenther; +Cc: gcc
Hi Richard,
Here is the relevant block from the dump:
<bb 3>:
__vect_var__26_6 = *__vect_p_14_19;
*__vect_p_18_25 = __vect_var__26_6;
# PT = nonlocal { __PARM_RESTRICT_2 } (restr)
__vect_p_22_11 = __vect_p_14_19 + 8;
# PT = nonlocal { __PARM_RESTRICT_1 } (restr)
__vect_p_27_12 = __vect_p_18_25 + 8;
__vect_var__26_45 = *__vect_p_22_11;
*__vect_p_27_12 = __vect_var__26_45;
I guess that it recognizes the restrict pointer so I don't understand
why later it creates a dependency between the insns.
Do you see here something relevant?
Thanks, Roy.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: vectorization, scheduling and aliasing
2010-04-26 13:51 ` roy rosen
@ 2010-04-26 14:34 ` Richard Guenther
2010-04-27 8:04 ` roy rosen
0 siblings, 1 reply; 9+ messages in thread
From: Richard Guenther @ 2010-04-26 14:34 UTC (permalink / raw)
To: roy rosen; +Cc: gcc
On Mon, Apr 26, 2010 at 3:42 PM, roy rosen <roy.1rosen@gmail.com> wrote:
> Hi Richard,
>
> Here is the relevant block from the dump:
>
> <bb 3>:
> __vect_var__26_6 = *__vect_p_14_19;
> *__vect_p_18_25 = __vect_var__26_6;
> # PT = nonlocal { __PARM_RESTRICT_2 } (restr)
> __vect_p_22_11 = __vect_p_14_19 + 8;
> # PT = nonlocal { __PARM_RESTRICT_1 } (restr)
> __vect_p_27_12 = __vect_p_18_25 + 8;
> __vect_var__26_45 = *__vect_p_22_11;
> *__vect_p_27_12 = __vect_var__26_45;
>
> I guess that it recognizes the restrict pointer so I don't understand
> why later it creates a dependency between the insns.
> Do you see here something relevant?
No, it looks good. At least if both __vect_p_22 and __vect_p_27
are restrict qualified.
The RTL dumps should show *__vect_p_27_12 and similar
expressions in their MEM_ATTRS as well.
Note that IVOPTs is known to not preserve alias information so
you might want to try -fno-ivopts
> Thanks, Roy.
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: vectorization, scheduling and aliasing
2010-04-26 14:34 ` Richard Guenther
@ 2010-04-27 8:04 ` roy rosen
0 siblings, 0 replies; 9+ messages in thread
From: roy rosen @ 2010-04-27 8:04 UTC (permalink / raw)
To: Richard Guenther; +Cc: gcc
Hi,
I have looked a bit more and tried also ia-64 and bfin and actually I
can't find a single example where vectorized code using __restrict__
variables would break the dependency between stores and loads.
for this simple program:
unsigned short xxx(unsigned short* __restrict__ a, unsigned short*
__restrict__ b)
{
int i;
for (i = 0; i < 8; i++)
{
a[i] = b[i];
}
return 0;
}
After unrolling and vectorization I get for all architectures that
there is a dependency between the first store (to a) and the second
load (from b).
since these are restrict variables I think this behavior is incorrect.
Can someone please show me such an example? Or is this feature not yet
supported?
Thanks, Roy.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2010-04-27 7:57 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-04-14 8:40 vectorization, scheduling and aliasing roy rosen
2010-04-14 11:07 ` Richard Guenther
2010-04-22 16:22 ` roy rosen
2010-04-23 12:12 ` Richard Guenther
2010-04-26 7:57 ` roy rosen
2010-04-26 11:24 ` Richard Guenther
2010-04-26 13:51 ` roy rosen
2010-04-26 14:34 ` Richard Guenther
2010-04-27 8:04 ` roy rosen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).