From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20878 invoked by alias); 14 Apr 2010 09:29:02 -0000 Received: (qmail 20864 invoked by uid 22791); 14 Apr 2010 09:29:01 -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-gw0-f47.google.com (HELO mail-gw0-f47.google.com) (74.125.83.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 14 Apr 2010 09:28:58 +0000 Received: by gwaa20 with SMTP id a20so1379555gwa.20 for ; Wed, 14 Apr 2010 02:28:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.79.14 with HTTP; Wed, 14 Apr 2010 02:28:56 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Apr 2010 11:07:00 -0000 Received: by 10.150.209.10 with SMTP id h10mr6055174ybg.287.1271237336212; Wed, 14 Apr 2010 02:28:56 -0700 (PDT) Message-ID: Subject: Re: vectorization, scheduling and aliasing From: Richard Guenther To: roy rosen Cc: gcc@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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/msg00320.txt.bz2 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) > { > =A0 =A0int __restrict__ i; > =A0 =A0for (i =3D 0; i < 8; i++) > =A0 =A0{ > =A0 =A0 =A0 =A0a[i] =3D b[i]; > =A0 =A0} > =A0 =A0return 0; > } > > from asmcons: > > (insn 17 14 18 3 a.c:15 (set (reg:V4HI 105) > =A0 =A0 =A0 =A0(mem:V4HI (reg/v/f:SI 100 [ b ]) [2 S8 A64])) 115 {*movv4h= i_load} (nil)) > > (insn 18 17 19 3 a.c:15 (set (mem:V4HI (reg/v/f:SI 99 [ a ]) [2 S8 A64]) > =A0 =A0 =A0 =A0(reg:V4HI 105)) 116 {*movv4hi_store} (expr_list:REG_DEAD (= reg:V4HI 105) > =A0 =A0 =A0 =A0(nil))) > > (insn 19 18 20 3 a.c:15 (set (reg:V4HI 106) > =A0 =A0 =A0 =A0(mem:V4HI (plus:SI (reg/v/f:SI 100 [ b ]) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(const_int 8 [0x8])) [2 S8 A64])) 115 {*mo= vv4hi_load} > (expr_list:REG_DEAD (reg/v/f:SI 100 [ b ]) > =A0 =A0 =A0 =A0(nil))) > > (insn 20 19 58 3 a.c:15 (set (mem:V4HI (plus:SI (reg/v/f:SI 99 [ a ]) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(const_int 8 [0x8])) [2 S8 A64]) > =A0 =A0 =A0 =A0(reg:V4HI 106)) 116 {*movv4hi_store} (expr_list:REG_DEAD (= reg:V4HI 106) > =A0 =A0 =A0 =A0(expr_list:REG_DEAD (reg/v/f:SI 99 [ a ]) > =A0 =A0 =A0 =A0 =A0 =A0(nil)))) > > =A0from sched1 - dependecies list: > =A0 --- Region Dependences --- b 3 bb 0 > ;; =A0 =A0 =A0insn =A0code =A0 =A0bb =A0 dep =A0prio =A0cost =A0 reservat= ion > ;; =A0 =A0 =A0---- =A0---- =A0 =A0-- =A0 --- =A0---- =A0---- =A0 --------= --- > ;; =A0 =A0 =A0 17 =A0 115 =A0 =A0 3 =A0 =A0 0 =A0 =A0 4 =A0 =A0 1 =A0 (2_= slots+lsu) =A0 =A0 =A0 : 58 20 18 > ;; =A0 =A0 =A0 18 =A0 116 =A0 =A0 3 =A0 =A0 1 =A0 =A0 3 =A0 =A0 1 =A0 (2_= slots+lsu) =A0 =A0 =A0 : 58 19 > ;; =A0 =A0 =A0 19 =A0 115 =A0 =A0 3 =A0 =A0 1 =A0 =A0 2 =A0 =A0 1 =A0 (2_= slots+lsu) =A0 =A0 =A0 : 58 20 > ;; =A0 =A0 =A0 20 =A0 116 =A0 =A0 3 =A0 =A0 2 =A0 =A0 1 =A0 =A0 1 =A0 (2_= slots+lsu) =A0 =A0 =A0 : 58 > ;; =A0 =A0 =A0 58 =A0 101 =A0 =A0 3 =A0 =A0 4 =A0 =A0 1 =A0 =A0 1 =A0 (3_= slots+pcu) =A0 =A0 =A0 : > > 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. >