From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41999 invoked by alias); 17 Aug 2015 16:01:51 -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 41983 invoked by uid 89); 17 Aug 2015 16:01:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-lb0-f177.google.com Received: from mail-lb0-f177.google.com (HELO mail-lb0-f177.google.com) (209.85.217.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 17 Aug 2015 16:01:49 +0000 Received: by lbbsx3 with SMTP id sx3so85181321lbb.0 for ; Mon, 17 Aug 2015 09:01:45 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.171.167 with SMTP id av7mr1691977lbc.48.1439827305631; Mon, 17 Aug 2015 09:01:45 -0700 (PDT) Received: by 10.25.158.69 with HTTP; Mon, 17 Aug 2015 09:01:45 -0700 (PDT) In-Reply-To: <55D1A77B.4070105@foss.arm.com> References: <20150723203112.GB27818@gate.crashing.org> <20150810082355.GA31149@arm.com> <55C8BFC3.3030603@redhat.com> <55D1A77B.4070105@foss.arm.com> Date: Mon, 17 Aug 2015 16:23:00 -0000 Message-ID: Subject: Re: [PR64164] drop copyrename, integrate into expand From: Andrew Pinski To: Kyrill Tkachov Cc: Alexandre Oliva , Andreas Schwab , Patrick Marlier , Jeff Law , James Greenhalgh , "H.J. Lu" , Segher Boessenkool , Richard Biener , GCC Patches , Christophe Lyon , David Edelsohn , Eric Botcazou Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00909.txt.bz2 On Mon, Aug 17, 2015 at 5:20 PM, Kyrill Tkachov wrote: > Hi Alexandre, > > On 17/08/15 03:56, Alexandre Oliva wrote: >> >> On Aug 16, 2015, Andreas Schwab wrote: >> >>> Alexandre Oliva writes: >>>> >>>> On Aug 15, 2015, Andreas Schwab wrote: >>>> >>>>> FAIL: gcc.target/aarch64/target_attr_crypto_ice_1.c (internal compiler >>>>> error) >>>>> In file included from >>>>> >>>>> /opt/gcc/gcc-20150815/gcc/testsuite/gcc.target/aarch64/target_attr_crypto_ice_1.c:4:0: >>>> >>>> Are you sure this is a regression introduced by my patch? >>> >>> Yes, it reintroduces the ICE. >> >> Ugh. I see this testcase was introduced very recently, so presumably it >> wasn't present in the tree that James Greenhalgh tested and confirmed >> there were no regressions. > > > Yeah, I introduced it as part of the SWITCHABLE_TARGET > work for aarch64. A bit of a mid-air collision :( > >> The hack in aarch64-builtins.c looks risky IMHO. Changing the mode of a >> decl after RTL is assigned to it (or to its SSA partitions) seems fishy. >> The assert is doing just what it was supposed to do. The only surprise >> to me is that it didn't catch this unexpected and unsupported change >> before. >> >> Presumably if we just dropped the assert in expand_expr_real_1, this >> case would work just fine, although the unsignedp bit would be >> meaningless and thus confusing, since the subreg isn't about a >> promotion, but about reflecting the mode change that was made from under >> us. >> >> May I suggest that you guys find (or introduce) other means to change >> the layout and mode of the decl *before* RTL is assigned to the params? >> I think this would save us a ton of trouble down the road. Just think >> how much trouble you'd get if the different modes had different calling >> conventions, alignment requirements, valid register assignments, or >> anything that might make coalescing their SSA names with those of other >> variables invalid. >> > I'm not familiar with the intricacies in this area but > I'll have a look. > Perhaps we can somehow re-layout the SIMD types when > switching from a non-simd to a simd target... > Can you, or Andreas please file a PR so we don't forget? How does x86 handle this case? Because it should be handling this case somehow. Thanks, Andrew > > Thanks, > Kyrill