From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32135 invoked by alias); 10 Aug 2011 11:40:51 -0000 Received: (qmail 32116 invoked by uid 22791); 10 Aug 2011 11:40:50 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-yw0-f47.google.com (HELO mail-yw0-f47.google.com) (209.85.213.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 10 Aug 2011 11:40:26 +0000 Received: by ywe9 with SMTP id 9so608551ywe.20 for ; Wed, 10 Aug 2011 04:40:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.92.20 with SMTP id u20mr8119558ybl.421.1312976425848; Wed, 10 Aug 2011 04:40:25 -0700 (PDT) Received: by 10.150.219.17 with HTTP; Wed, 10 Aug 2011 04:40:25 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Aug 2011 11:40:00 -0000 Message-ID: Subject: Re: Move insn out of the way From: Richard Guenther To: "Paulo J. Matos" 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: 2011-08/txt/msg00203.txt.bz2 On Wed, Aug 10, 2011 at 12:29 PM, Paulo J. Matos wr= ote: > Hi, > > I am having a size optimisation issue with GCC-4.6.1. > The problem boils down to the fact that I have no idea on the best way to > hint to GCC that a given insn would make more sense someplace else. > > The C code is simple: > int16_t mask(uint32_t a) > { > =A0 =A0return (x & a) =3D=3D a; > } > > int16_t is QImode and uint32_t is HImode. > After combine the insn chain (which is unmodified all the way to ira) is = (in > simplified form): > regQI 27 <- regQI AH [a] > regQI 28 <- regQI AL [a+1] > regQI AL <- andQI(regQI 28, memQI(symbolrefQI(x) + 1)) > regQI AH <- andQI(regQI 27, memQI(symbolrefQI(x)) > regQI 30 <- regQI AL > regQI 29 <- regQI AH > regQI 24 <- 1 > if regQI 29 !=3D regQI 27 > =A0 goto labelref 20 > if regQI 30 !=3D regQI 28 > =A0 goto labelref 20 > goto labelref 22 > labelref 20 > regQI 24 <- 0 > labelref 22 > regQI AL <- regQI 24 > > The problem resides in `regQI 24 <- 1' being before the jumps. > Since regQI 24 is going to AL, IRA decides to allocate regQI 24 to AL, wh= ich > creates loads of conflicts and reloads. If that same insn would be moved = to > after the jumps and before the `goto labelref 22' then all would be fine > cause by then regs 27, 28, 29, 30 are dead. > > It's obviously hard to point to a solution but I was wondering if there's= a > way to hint to GCC that moving an insn might help the code issue. Or if I > should look into a why an existing pass is not already doing that. On x86 we expand the code to ((xl & al) ^ al) | ((xh & ah) ^ ah) =3D=3D 0 which is then if-converted. Modified testcase: long long x; _Bool __attribute__((regparm(2))) mask (long long a) { return (x & a) =3D=3D a; } on i?86 gets you mask: .LFB0: .cfi_startproc pushl %ebx .cfi_def_cfa_offset 8 .cfi_offset 3, -8 movl %eax, %ebx andl x, %ebx movl %edx, %ecx andl x+4, %ecx xorl %ebx, %eax xorl %ecx, %edx orl %edx, %eax sete %al popl %ebx .cfi_restore 3 .cfi_def_cfa_offset 4 ret so I wonder if you should investigate why the xor variant doesn't trigger for you? On i?86 if-conversion probably solves your specific issue, but I guess the initial expansion is where you could improve placement of the 1 (after all, the 0 is after the jumps). Richard. > Cheers, > > -- > PMatos > >