From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96292 invoked by alias); 11 May 2017 14:02:10 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 96265 invoked by uid 89); 11 May 2017 14:02:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 11 May 2017 14:02:07 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 7BE43ABCA; Thu, 11 May 2017 14:02:08 +0000 (UTC) Date: Thu, 11 May 2017 14:06:00 -0000 From: Richard Biener To: Uros Bizjak cc: Rainer Orth , "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH] Fix PR79201 (half-way) In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2017-05/txt/msg00899.txt.bz2 On Thu, 11 May 2017, Uros Bizjak wrote: > On Thu, May 11, 2017 at 2:48 PM, Richard Biener wrote: > > On Thu, 11 May 2017, Rainer Orth wrote: > > > >> Hi Richard, > >> > >> > On Mon, 24 Apr 2017, Richard Biener wrote: > >> >> > >> >> One issue in PR79201 is that we don't sink pure/const calls which is > >> >> what the following simple patch fixes. > >> >> > >> >> Bootstrap and regtest running on x86_64-unknown-linux-gnu. > >> > > >> > Needed some gimple_assign_lhs -> gimple_get_lhs adjustments and > >> > adjustment of gcc.target/i386/pr22152.c where we now sink the > >> > assignment out of the pointless loop. Not sure what the original > >> > bug was about (well, reg allocation) so I simply disabled sinking > >> > for it. > >> > > >> > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. > >> > > >> > Richard. > >> > > >> > 2017-04-25 Richard Biener > >> > > >> > PR tree-optimization/79201 > >> > * tree-ssa-sink.c (statement_sink_location): Handle calls. > >> > > >> > * gcc.dg/tree-ssa/ssa-sink-16.c: New testcase. > >> > * gcc.target/i386/pr22152.c: Disable sinking. > >> > >> however, gcc.target/i386/pr22152.c FAILs now for 32-bit: > >> > >> FAIL: gcc.target/i386/pr22152.c scan-assembler-times movq[ \\\\t]+[^\\n]*%mm 1 > > > > I remember seeing this and was not able to make sense of the testcase > > which was added to fix some backend issue. Disabling sinking doesn't > > work (IIRC) as it is required to generate the original code as well. > > > > Uros added the testcase in 2008 -- I think if we want to have a testcase > > for the original issue we need a different one. Or simply remove > > the testcase. > > No, there is something going on in the testcase: > > .L3: > movq (%ecx,%eax,8), %mm1 > paddq (%ebx,%eax,8), %mm1 > addl $1, %eax > movq %mm1, %mm0 > cmpl %eax, %edx > jne .L3 > > > The compiler should allocate %mm0 to movq and paddq to avoid %mm1 -> > %mm0 move. These are all movv1di patterns (they shouldn't interfere > with movdi), and it is not clear to me why RA allocates %mm1 instead > of %mm0. In any case the testcase is no longer testing what it tested as the input to RA is now different. The testcase doesn't make much sense: __m64 unsigned_add3 (const __m64 * a, const __m64 * b, unsigned int count) { __m64 sum; unsigned int i; for (i = 1; i < count; i++) sum = _mm_add_si64 (a[i], b[i]); return sum; } that's equivalent to __m64 unsigned_add3 (const __m64 * a, const __m64 * b, unsigned int count) { __m64 sum; unsigned int i; if (1 < count) sum = _mm_add_si64 (a[count-1], b[count-1]); return sum; } which means possibly using uninitialized sum plus a pointless loop. Richard.