From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7489 invoked by alias); 22 Apr 2010 16:04:25 -0000 Received: (qmail 7297 invoked by uid 22791); 22 Apr 2010 16:04:21 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,SARE_MSGID_LONG45 X-Spam-Check-By: sourceware.org Received: from mail-ww0-f47.google.com (HELO mail-ww0-f47.google.com) (74.125.82.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 22 Apr 2010 16:04:16 +0000 Received: by wwb18 with SMTP id 18so5347565wwb.20 for ; Thu, 22 Apr 2010 09:04:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.0.145 with HTTP; Thu, 22 Apr 2010 09:04:12 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 Apr 2010 16:22:00 -0000 Received: by 10.216.168.71 with SMTP id j49mr7011103wel.175.1271952254328; Thu, 22 Apr 2010 09:04:14 -0700 (PDT) Message-ID: Subject: Re: vectorization, scheduling and aliasing From: roy rosen To: Richard Guenther Cc: gcc@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2010-04/txt/msg00532.txt.bz2 Hi Richard, 2010/4/14, Richard Guenther : > On Wed, Apr 14, 2010 at 8:48 AM, roy rosen 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.