From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33552 invoked by alias); 17 May 2016 16:08:36 -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 33539 invoked by uid 89); 17 May 2016 16:08:35 -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,SPF_PASS autolearn=ham version=3.3.2 spammy=obscure, handy, workarounds, ties 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; Tue, 17 May 2016 16:08:24 +0000 Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0083.outbound.protection.outlook.com [213.199.154.83]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-26-BeQVRMZ3Ss2rJI0H49rkXA-1; Tue, 17 May 2016 17:08:18 +0100 Received: from AM3PR08MB0088.eurprd08.prod.outlook.com (10.160.211.18) by DB5PR08MB0920.eurprd08.prod.outlook.com (10.166.13.139) with Microsoft SMTP Server (TLS) id 15.1.497.12; Tue, 17 May 2016 16:08:17 +0000 Received: from AM3PR08MB0088.eurprd08.prod.outlook.com ([fe80::3c8a:85da:37cb:7d46]) by AM3PR08MB0088.eurprd08.prod.outlook.com ([fe80::3c8a:85da:37cb:7d46%16]) with mapi id 15.01.0497.019; Tue, 17 May 2016 16:08:17 +0000 From: Wilco Dijkstra To: James Greenhalgh CC: "gcc-patches@gcc.gnu.org" , nd Subject: Re: [PATCH][AArch64] Improve aarch64_modes_tieable_p Date: Tue, 17 May 2016 16:08:00 -0000 Message-ID: References: ,<20160427144829.GA1066@arm.com> In-Reply-To: <20160427144829.GA1066@arm.com> x-ms-office365-filtering-correlation-id: 1ea7fa9c-8dc2-4e89-c871-08d37e6d754b x-microsoft-exchange-diagnostics: 1;DB5PR08MB0920;5:kQj8AXNIgoPse2fgyzfMvqDzxch0awHR1LUNjVmcOAZ+9rcjgJ4L9ldwBa/wKZy5l7esvrdCnYe1/MnVxFCshxDDqsjfbdrb6rgH7MY1xS1iddmUm2lJJUJPIprY07FAe/vM+bO8M7fOuegqbIi10g==;24:sbv6x2wITUdYG7ri/5OzSw9TuIYPOvNf6fCmDWPdg1Bu/HXy4vv9s8P9XzZs/hwdzBpActfLermPjeGlkq4KFvOKkwg4MhhS8gx+VTszo/Y=;7:CiZwg08Fo7edrG6fUVZtRecb9HK9/z3KNwhFFgtZdYTZICGR2rGQqm3o0ZXH0kXSyO3Z9CDuXV1GIoWmX0amTzU7Y2nmuSF5xLBVQSGCrabtp/vW+IQ48DV/UXgS+//fjd1Sj1Z1hRc9D2+6m/4tFGC1XqeHVzJyQV8XJCfFzwOSL1r8tpHQnKD7nL8Gb43g;20:Y1xCoy3Lx69KZ/ywkgcNEyRsVWfYoazbQ2G6W3Y9tjZAU7GRFRnOPyoWh4prVoYeythc0Bse710jpBF0Cs7h4nS6xW0CnulY7gDhYmwtp7NXXjwqvfJKxlQdU+4trbLb4Y1IxQmndDXKR0LvAV+E0CGvqu3EJfj0TvpnEPFwh6k= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR08MB0920; nodisclaimer: True x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026);SRVR:DB5PR08MB0920;BCL:0;PCL:0;RULEID:;SRVR:DB5PR08MB0920; x-forefront-prvs: 0945B0CC72 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(24454002)(86362001)(1220700001)(9686002)(5250100002)(6116002)(102836003)(4326007)(11100500001)(2900100001)(50986999)(54356999)(76176999)(2906002)(110136002)(189998001)(66066001)(5004730100002)(2950100001)(5008740100001)(5003600100002)(92566002)(8676002)(81166006)(450100001)(33656002)(8936002)(76576001)(3846002)(586003)(87936001)(106116001)(74316001)(5002640100001)(15760500001);DIR:OUT;SFP:1101;SCL:1;SRVR:DB5PR08MB0920;H:AM3PR08MB0088.eurprd08.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2016 16:08:17.2088 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR08MB0920 X-MC-Unique: BeQVRMZ3Ss2rJI0H49rkXA-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2016-05/txt/msg01266.txt.bz2 James Greenhalgh wrote: > It would be handy if you could raise something in bugzilla for the > register allocator deficiency. The register allocation issues are well known and we have multiple workarounds for this in place. When you allow modes to be tieable the workarounds are not as effective. > - if (TARGET_SIMD > - && aarch64_vector_mode_p (mode1) > - && aarch64_vector_mode_p (mode2)) > + if (aarch64_vector_mode_p (mode1) && aarch64_vector_mode_p (mode2)) > + return true; > This relaxes the TARGET_SIMD check that would have prevented > OImode/CImode/XImode ties when !TARGET_SIMD. What's the reasoning > behind that? There is no need for TARGET_SIMD checks here - in order to create a vector_struct mode you need to call aarch64_array_mode_supported_p first. > + /* Also allow any scalar modes with vectors. */ > + if (aarch64_vector_mode_supported_p (mode1) > + || aarch64_vector_mode_supported_p (mode2)) > return true; > Does this always hold? It seems like you might need to be more restrictive > with what we allow to avoid ties with some of the more obscure modes > (V4DF etc.). Well it is safe to always return true - this passes regression tests (it's = just a bad idea from a CQ point of view). Wilco