From patchwork Sun May 29 18:24:02 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chung-Lin Tang X-Patchwork-Id: 1662 Return-Path: Delivered-To: unknown Received: from imap.gmail.com (74.125.159.109) by localhost6.localdomain6 with IMAP4-SSL; 08 Jun 2011 14:54:01 -0000 Delivered-To: patches@linaro.org Received: by 10.52.110.9 with SMTP id hw9cs200521vdb; Sun, 29 May 2011 11:24:15 -0700 (PDT) Received: by 10.42.41.129 with SMTP id p1mr3103080ice.365.1306693454820; Sun, 29 May 2011 11:24:14 -0700 (PDT) Received: from mail.codesourcery.com (mail.codesourcery.com [38.113.113.100]) by mx.google.com with ESMTPS id d5si16824840icu.125.2011.05.29.11.24.14 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 May 2011 11:24:14 -0700 (PDT) Received-SPF: pass (google.com: domain of cltang@codesourcery.com designates 38.113.113.100 as permitted sender) client-ip=38.113.113.100; Authentication-Results: mx.google.com; spf=pass (google.com: domain of cltang@codesourcery.com designates 38.113.113.100 as permitted sender) smtp.mail=cltang@codesourcery.com Received: (qmail 30231 invoked from network); 29 May 2011 18:24:12 -0000 Received: from unknown (HELO ?192.168.1.16?) (cltang@127.0.0.2) by mail.codesourcery.com with ESMTPA; 29 May 2011 18:24:12 -0000 Message-ID: <4DE28F42.2070507@codesourcery.com> Date: Mon, 30 May 2011 02:24:02 +0800 From: Chung-Lin Tang User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: gcc-patches CC: Richard Earnshaw , patches@linaro.org Subject: [patch, ARM] Fix PR48808, PR48792: More work on CANNOT_CHANGE_MODE_CLASS Hi, revision 171520 changed ARM's CANNOT_CHANGE_MODE_CLASS to loosen up on VFP registers. Richard Sandiford mentioned it being essential for accessing individual lanes/subregs of vector types. PR48808 and PR48792 basically triggered after the change due to insns like: (insn 39 41 43 2 (set (subreg:SI (reg:HI 234) 0) (fix:SI (fix:DF (reg:DF 77 s14 [233])))) t.i:32 666 {*truncsidf2_vfp} (expr_list:REG_DEAD (reg:DF 77 s14 [233]) (nil))) The output reload trips over when seeing that we can go from SI-->HI in VFP_LO_REGS (CANNOT_CHANGE_MODE_CLASS now returning 0) by attempting to place an HImode into VFP_LO_REGS... This patch tries to fix this by adding back the reg_classes_intersect_p() check, plus further tests to ensure both FROM/TO modes are actually (not) valid for VFP registers. An alternative fix direction would be to add similar mode/regclass validity checks to all places where CANNOT_CHANGE_MODE_CLASS is used in the RTL core, which may stratify things a bit more (the internals documentation does not mention anything on whether the backend should check this mode/regclass condition by itself). But this seems a bit scattered and probably a little risky, so I'll settle for the ARM specific fix for now. This is still pending testing, but the testcases for the two PRs no longer ICE with this fix. It should also not interfere with Richard S' original NEON lane access intention. Okay for trunk if tests pass? Thanks, Chung-Lin 2011-05-30 Chung-Lin Tang PR target/48808 PR target/48792 * config/arm/arm.h (CANNOT_CHANGE_MODE_CLASS): Return true when FROM or TO modes are invalid for VFP registers. Index: config/arm/arm.h =================================================================== --- config/arm/arm.h (revision 174395) +++ config/arm/arm.h (working copy) @@ -1103,6 +1103,9 @@ #define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \ (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \ ? reg_classes_intersect_p (FPA_REGS, (CLASS)) \ + || (reg_classes_intersect_p (VFP_REGS, (CLASS)) \ + && (! HARD_REGNO_MODE_OK (FIRST_VFP_REGNUM, (FROM)) \ + || ! HARD_REGNO_MODE_OK (FIRST_VFP_REGNUM, (TO)))) \ : 0) /* The class value for index registers, and the one for base regs. */