On Wed, Apr 14, 2010 at 8:48 AM, roy rosen <roy.1ro...@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. >