From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105437 invoked by alias); 18 Nov 2015 15:27:02 -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 103598 invoked by uid 89); 18 Nov 2015 15:27:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: eu-smtp-delivery-143.mimecast.com Received: from eu-smtp-delivery-143.mimecast.com (HELO eu-smtp-delivery-143.mimecast.com) (207.82.80.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 18 Nov 2015 15:27:00 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-26-G028li5oTImHy-ve1rVYtw-1; Wed, 18 Nov 2015 15:26:54 +0000 Received: from [10.2.206.200] ([10.1.2.79]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2015 15:26:54 +0000 Message-ID: <564C98BD.1050101@arm.com> Date: Wed, 18 Nov 2015 15:27:00 -0000 From: Kyrill Tkachov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: GCC Patches CC: Ramana Radhakrishnan , Richard Earnshaw Subject: Re: [PATCH][ARM] PR 68149 Fix ICE in unaligned_loaddi split References: <56422A10.80500@arm.com> In-Reply-To: <56422A10.80500@arm.com> X-MC-Unique: G028li5oTImHy-ve1rVYtw-1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg02230.txt.bz2 Ping. https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01253.html Thanks, Kyrill On 10/11/15 17:32, Kyrill Tkachov wrote: > Hi all, > > This ICE in this PR occurs when we're trying to split unaligned_loaddi in= to two SImode unaligned loads. > The problem is in the addressing mode. When reload was picking the addre= ssing mode we accepted an offset of > -256 because the mode in the pattern is advertised as DImode and that was= accepted by the legitimate address > hooks because they thought it was a NEON load (DImode is in VALID_NEON_DR= EG_MODE). However, the splitter wants > to generate two normal SImode unaligned loads using that address, for whi= ch -256 is not valid, so we ICE > in gen_lowpart. > > The only way unaligned_loaddi could be generated was through the gen_movm= em_ldrd_strd expansion that implements > a memmove using LDRD and STRD sequences. If the memmove source is not ali= gned we can't use LDRDs so the code > generates unaligned_loaddi patterns and expects them to be split into two= normal loads after reload. Similarly > for unaligned store destinations. > > This patch just explicitly generates the two unaligned SImode loads or st= ores when appropriate inside > gen_movmem_ldrd_strd. This makes the unaligned_loaddi and unaligned_stor= edi patterns unused, so we can remove them. > > This patch fixes the ICe in gcc.target/aarch64/advsimd-intrinsics/vldX.c = seen with > -mthumb -mcpu=3Dcortex-a15 -mfpu=3Dneon-vfpv4 -mfloat-abi=3Dhard -mfp16-f= ormat=3Dieee > so no new testcase is added. > > Bootstrapped and tested on arm-none-linux-gnueabihf. > > Ok for trunk? > > Thanks, > Kyrill > > 2015-11-10 Kyrylo Tkachov > > PR target/68149 > * config/arm/arm.md (unaligned_loaddi): Delete. > (unaligned_storedi): Likewise. > * config/arm/arm.c (gen_movmem_ldrd_strd): Don't generate > unaligned DImode memory ops. Instead perform two back-to-back > unalgined SImode ops.