From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121250 invoked by alias); 28 Nov 2017 18:15:37 -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 91213 invoked by uid 89); 28 Nov 2017 18:15:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 spammy=H*RU:sk:AM5EUR0, H*r:sk:AM5EUR0, Hx-spam-relays-external:sk:AM5EUR0, Hx-spam-relays-external:15.20.282.5 X-HELO: EUR01-VE1-obe.outbound.protection.outlook.com Received: from mail-ve1eur01on0089.outbound.protection.outlook.com (HELO EUR01-VE1-obe.outbound.protection.outlook.com) (104.47.1.89) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 28 Nov 2017 18:15:13 +0000 Received: from VI1PR0802CA0027.eurprd08.prod.outlook.com (2603:10a6:800:a9::13) by DB4PR08MB0141.eurprd08.prod.outlook.com (2a01:111:e400:985d::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Tue, 28 Nov 2017 18:15:05 +0000 Received: from AM5EUR03FT004.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e08::202) by VI1PR0802CA0027.outlook.office365.com (2603:10a6:800:a9::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.282.5 via Frontend Transport; Tue, 28 Nov 2017 18:15:04 +0000 Authentication-Results: spf=pass (sender IP is 217.140.96.140) smtp.mailfrom=arm.com; gcc.gnu.org; dkim=none (message not signed) header.d=none;gcc.gnu.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 217.140.96.140 as permitted sender) receiver=protection.outlook.com; client-ip=217.140.96.140; helo=nebula.arm.com; Received: from nebula.arm.com (217.140.96.140) by AM5EUR03FT004.mail.protection.outlook.com (10.152.16.163) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.20.239.4 via Frontend Transport; Tue, 28 Nov 2017 18:15:03 +0000 Received: from arm.com (10.1.2.79) by mail.arm.com (10.1.106.66) with Microsoft SMTP Server id 14.3.294.0; Tue, 28 Nov 2017 18:15:01 +0000 Date: Tue, 28 Nov 2017 18:40:00 -0000 From: James Greenhalgh To: Wilco Dijkstra CC: GCC Patches , nd Subject: Re: [PATCH][AArch64] Fix ICE due to store_pair_lanes Message-ID: <20171128181500.GA25893@arm.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:217.140.96.140;IPV:CAL;SCL:-1;CTRY:GB;EFV:NLI;SFV:NSPM;SFS:(10009020)(979002)(6009001)(376002)(346002)(39860400002)(2980300002)(438002)(24454002)(199003)(189002)(5660300001)(97756001)(8676002)(189998001)(76176999)(8936002)(23726003)(4326008)(6246003)(54356999)(6862004)(246002)(6286002)(50986999)(1076002)(47776003)(229853002)(36756003)(104016004)(356003)(305945005)(55016002)(478600001)(46406003)(50466002)(26826003)(72206003)(83506002)(2950100002)(2906002)(106466001)(86362001)(54906003)(106002)(7696005)(58126008)(16586007)(37006003)(33656002)(6636002)(316002)(77096006)(18370500001)(969003)(989001)(999001)(1009001)(1019001);DIR:OUT;SFP:1101;SCL:1;SRVR:DB4PR08MB0141;H:nebula.arm.com;FPR:;SPF:Pass;PTR:fw-tnat.cambridge.arm.com;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;AM5EUR03FT004;1:FNP3Z1qsYFCzoVWVEOduZuCos+XBKSSaZcFl6Wvv1saGm7B3BefBSfUWD5T3l1NsiF3Y7mIj5t62NnLJqXocxHrGZpTAv47HVE3wrRMsKeBT386jJ6XmznHiXWLSB4Oc X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0e54fb3d-5f54-424a-049c-08d5368bf268 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(5600026)(4604075)(4608076)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258);SRVR:DB4PR08MB0141; X-Microsoft-Exchange-Diagnostics: 1;DB4PR08MB0141;3:TLjZvY2hGFkldRsnV9TtIoQyO3c7VovuWE2pWjOYGhx4Jt7LCy8JrTYaArXoygVktXDM9kZlyXajgtJSxvmv2xz9W6V9a6okL7F8lcitoMDMX+utHe1/mduTEbVnZUO81CuyAKtblFJUD9Sstykx2jUAX9rJ3e7ZMKfDTJBU9g8ueFxEMHHPUfQkebQamtg23y4GDxXIEyNmYa05iP7Uk6RhK7Y7gzoxOmCo5bo4tX3tyur7PfxKizAiq6ZcHoDCCsLihZtKO/Is+M7i+lK7llsEqBnFGaJUifcG/Of+vHIG/oocSfw28MeEOu2Q/b23S3IOo3nOrIVgxqv58ipdcSTdiy+koBySob0f2aByUBk=;25:ZVuFVgkEAqCTCIP0CXW5AOB/63Zdit6/bAFOWNeB+Oc0lHlCA8SYyO2nXLUa8AYR3CF3WZXe5pUenwQnwNceAqVWxMWOACNt0AVTdsMN1Sv0L34HUN85bRZrLbCQIz/COpXEOSZgkW6hzFFOMPlDEIJm4n52C+bh+LH2jW4kQ6aktAE7Vl891ODo8yWkT2V1unGOUPISE3JaflM3PUbdAAbbjQcNLHpqD6MSRuAJVYz06lv/5TG3Y8l/FnRyq8HdjK9kz56O3DVHdezNCZ7Iw8bhNK5a+f8m3ZdabV2NUVgBfVj3KcssvEQkY/Qa+yH8Y3mOi4YIxVhv5HLcS8Kie7PCYVfn82acmsGP3c2hcYc= X-MS-TrafficTypeDiagnostic: DB4PR08MB0141: X-Microsoft-Exchange-Diagnostics: 1;DB4PR08MB0141;31:bp9FG+kEJJjd1KzfyeGjrvEE5AQ98/sg1FJ/Pn00KTGhGoDNOEEJQy1236uZo6m41ULqbnVLfzMkOdzHT5h/7lJSjxGfJPfFadCUqRf3SpnuokhtefJbwTbv0XATgbPS7yLytSdvMJPMqw6xffBgAydYvmrnsIdr/niVDCbccd8EJa6127+vzIJEQpf6q7mbVHdUuWo1arjksXxgk7DVQTG+6bfwAlchnbY50+8RzBc=;20:ISt84yPZHDjSZv5TzSbQS33E4mwd7KP/gsgqdIahnL94P/UMSuuuYbLhrsFuOYqf1zuCI344TA9lwMVLO4ZwdAGcFRdOoRSC8wEOyfRaZuxiGzMwS/39jBuXJmjzMk4hHbcki834L/YkTf+qNu+dohDXXJXabCTKE3ETcN4Q1M6+jLqjOy4cHTQBgZSJ1RYwBVEfODodxSqhvuCMMBt2oN1h0Ix/dBRr5NIswUi4W4mDzOVMh53YkH6G2Oz+wkah;4:fyaOHaVU2UFplAJ06tUKV60D7iJeorD8N5fSN9EM/mwGZIetK9gqRPz1BxP+WDL0tBoz66IZCBPADbhYHYaevdgO7FlInFqVEGu3xtDsN1ASWKv9RttJyQGoc0J5Izwx6xITkA4TbedVTfy1iEBNufj/QPhQfzv/PFCdSw46SroT4majpbUalAmL9z7hrVQUYL/BWrAuiqDIWdwT1jcKFwPvEXhQIihnfyVN+KeMu8XV4V9WKAwVuMmcvIGkbCjJLgooXl17hC0Cv3iRpDHOsg== NoDisclaimer: True X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93004095)(3002001)(3231022)(6055026)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011);SRVR:DB4PR08MB0141;BCL:0;PCL:0;RULEID:(100000803101)(100110400095);SRVR:DB4PR08MB0141; X-Forefront-PRVS: 0505147DDB X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;DB4PR08MB0141;23:irDENPowsAB6tFKCVz3dGTfzsz2ShuN1pp1jYQDT+?= =?us-ascii?Q?rmLoC9qJTWZbka9sima7eb/Lq2vr7sBkR61b5HAXrx2paICRgBHo6dnIHvDZ?= =?us-ascii?Q?Mw4C7VEmjL9Z09FlIiV0vPc71oz80kjEMqAVBWzP3arV9mg4CTbh3dx3U04A?= =?us-ascii?Q?0fmgfS+ubVd/R0LnUeFlEH3A5ClauMIuTLZmrIkPp+tzIAdK/O84O4iLJ0ef?= =?us-ascii?Q?J2fSONpWUYZfHtzZXuSYYjCeV/FQdc6xqlWhUgQfK4WOiFykxQ0Eb6oeK39f?= =?us-ascii?Q?v3ybRuIXQUNvvfLrCUrbbSiQVL9Jy8FPPUYG6+Skoe+oxt9PGGqY/xYLbAVr?= =?us-ascii?Q?IA9ofvqzqeNB3PuA71QHKEbcf0MW6zWAjFCQnMm7XqWpaIxRM3X7ku3v0au6?= =?us-ascii?Q?HkZtbPtbL2g33nYDdb7dgapqBa/G1+Vi4GmUclrd0GR9AOKTf8zLPOrIDquD?= =?us-ascii?Q?mA7NXcfa71ljnrj0CI5uoW7Uiqd6Az+1tKbzvwnRAfKDNBNUG7iHwlFS4jh0?= =?us-ascii?Q?KLa6AqsPHEHyd+F8J9Y3VH4DNglTNxxk2/5GsPfSdOcXZkpZWK1noZBFBs2P?= =?us-ascii?Q?yKafAQFdZudeVhTyA4qlftgu2sT0hXRozqSztII173qA74oVcT8JGmrvoQq7?= =?us-ascii?Q?/CeZmKqX3SDWs3pSvQrhVr+XY1T1EcRUYZ8KsXGHblbnD+T1KOeb/KwyhvS2?= =?us-ascii?Q?4mdbIob7fFx+vhoCfk7wkFxz4hXZY4aOJjGrASuOCWqo+Na6e/6ViHZN3dDO?= =?us-ascii?Q?CbSHYj3W9nVO/MBncxGXuF7IfZ/TMqXjQsN1qIUAgPHQrmQhgWql0XZKJKsd?= =?us-ascii?Q?XWFmlnTdFK35SJTMGGEfM15GaMdlb+PxzdY6HuAqh4Y8ETezZageP4wKaKtx?= =?us-ascii?Q?ZqQPSKKXsVEFLlrh3sginyu2eMiGfw/53CenSoGJ4f4a3e8SBdICHG+OXKTx?= =?us-ascii?Q?DJPAF/cPFsAVqwJOEzKW+VN9fd8s2y7pdk4iKoULMPRRCYLnqfUd501l3DvU?= =?us-ascii?Q?nWsEGJK2573X/5/2yNVW9t8LyOqrjCVgdaI7n24h5qmJcYoXQ/Hl5uicSma3?= =?us-ascii?Q?4cUfIHbxK5vCkkuQK4MN/bIvHLzSQKvKRIovhMdt92LwK4DXQ2ert734WFBT?= =?us-ascii?Q?0Y6rR9V0WHPcITB4EtlESIDzS+HFoKI3+WvQmvKgQ0ybnBFb5kIEDdR+GHPk?= =?us-ascii?Q?q3ZvywYXO4pfTnm1jzWt+QzPUCh9TrSMXN5no823ptyqA7SOHS5/XRzhKk3F?= =?us-ascii?Q?j54uxvHOIKJMBYx/X69UflDhLnmtW/x2+J24xlnk68MnE0VL8+bzsFMYefgW?= =?us-ascii?B?QT09?= X-Microsoft-Exchange-Diagnostics: 1;DB4PR08MB0141;6:zz+m+JvXvTsBc8lLRoFAqy6oOLv0OcVh5/ame+XZzNpBdhcsTaYv864QPYpD3v7ykz+YL109r7usjPk9RzD6TbkUX7r36fyg2cnsZgiINpwbQpZM2RDk8WSkWDyog6ID9hHmd13TJMN+nMeW3pZQkB4S/e8zq64b/OfL77dLm6s4qpSBk6Jx9zphCD3hMai15pzM/Np7LdeuYlfbpvbQdxymtZc9JHgfUs2MoLl53JOzIG+TqeA/ydGezuM4quQDfBOMlP0kwI5Cu5eujSIDuqe3TwFOIP2VCTnv08eatX7dEPQhCuaESdsdw7br4uUAs3j+9BD8L502c5vJ1lYU9NdBd3qveYiJg/1YHnxRMRw=;5:0lVcL46HxW7E+YjYOKgRfANPdtsb0XRw53Fh01JmS7LTapTFTRAvGBBKACmG+c8ay2SNGz8tPqd7N+l68IpBpJEM+q8VIUqo1HvLyMWscEuxurT0jQEeSySHAAYVPELczxYC7TuFu93LtN+z+sGZK5GBmAy+aRJ1klBj5crcXi8=;24:FsBgBNJBrB7eET+Bp8AO/bXkgnaI3XQtT6ouG69SRlsMvWp6QBH69sFFfyO79Mi76ZMpf87QHla6qgJU6OV44ny0aEU63sdkul+5w/pS4xU=;7:6KdNjvGmHyKYFUMsfNLAkNMWWM46C0syG03NgacMuSmXG+bbQEBoEDTYncAX6WHIRy+M40R3Ijr+YWWuGGcvf03NyXtMobEOQbs4A+8LD5txOJtL96IMyMhCXUfROr4c1EUp+9qrbIbZ7xN06D2iT2J85nDcdTdymRmAdmjsA4hNoZt38FiQrL7S2TWaFCuW316Acn/J/ULGfsj7yfRmxNWunzBQir+tTo0vTDISVdZChB0dNvVXHaPHE1tKtcYQ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Nov 2017 18:15:03.4925 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0e54fb3d-5f54-424a-049c-08d5368bf268 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[217.140.96.140];Helo=[nebula.arm.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR08MB0141 X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg02454.txt.bz2 On Mon, Nov 27, 2017 at 03:20:29PM +0000, Wilco Dijkstra wrote: > The recently added store_pair_lanes causes ICEs in output_operand. > This is due to aarch64_classify_address treating it like a 128-bit STR > rather than a STP. The valid immediate offsets don't fully overlap, > causing it to return false. Eg. offset 264 is a valid 8-byte STP offset > but not a valid 16-byte STR offset since it isn't a multiple of 16. > > The original instruction isn't passed in the printing code, so the context > is unclear. The solution is to add a new operand formatting specifier > which is used for LDP/STP instructions like this. This, like the Uml > constraint that applies to store_pair_lanes, uses PARALLEL when calling > aarch64_classify_address so that it knows it is an STP. > Also add the 'z' specifier for future use by load/store pair instructions. > > Passes regress, OK for commit? OK. But... > + if (aarch64_classify_address (&addr, x, mode, op, true)) This interface is not nice, resulting in... > +/* Print address 'x' of a LDP/STP with mode 'mode'. */ > +static void > +aarch64_print_ldpstp_address (FILE *f, machine_mode mode, rtx x) > +{ > + aarch64_print_address_internal (f, mode, x, PARALLEL); > +} > + > +/* Print address 'x' of a memory access with mode 'mode'. */ > +static void > +aarch64_print_operand_address (FILE *f, machine_mode mode, rtx x) > +{ > + aarch64_print_address_internal (f, mode, x, MEM); > +} These, which I *really* dislike. Ideas on how to clean up this interface would be appreciated. Thanks, James