From patchwork Thu Nov 14 12:34:13 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kwok Cheung Yeung X-Patchwork-Id: 1194806 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-513377-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="LG9YBaDD"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 47DLY00lVHz9s7T for ; Thu, 14 Nov 2019 23:35:15 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :subject:to:message-id:date:mime-version:content-type :content-transfer-encoding; q=dns; s=default; b=jxDAb6DKJSQ0su/P 4pHhA7B0OCYtEcZ6hBb9zBf+VzrpWkgqbIUgUD7ZItCFobM6KeKo2XoJ5ftNUL4c xV0lC6q9ygNHh2R3Uwjrd9dBBYaEbMaUgEHhfsGZql1BJ0Ccm/x015IGabwv/Jy1 wZSavlPxwMb5tRZoiCDskDWgGV4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :subject:to:message-id:date:mime-version:content-type :content-transfer-encoding; s=default; bh=2UiYsAKyTJ0hLcIPksyFYs 9gvlQ=; b=LG9YBaDD+sX2Tl9f8/Yh160lOegu7IkpI3Lsws9t2fhZjXZ44mvHK5 MAjDRKzECoCW1NDdU+apPTTqVa0xAM1lPP12GV1qe2u3gWPkrVl078FyZqSZ72t3 Lwnzv34+JPuKsEwozi60JEAdlNkmpifGz13gyW4LSb4Wn7bFfVlJo= Received: (qmail 125931 invoked by alias); 14 Nov 2019 12:35:09 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 125919 invoked by uid 89); 14 Nov 2019 12:35:09 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-19.4 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3 autolearn=ham version=3.3.1 spammy=kwok, sk:kcy@cod, Kwok, H*UA:x64 X-HELO: esa2.mentor.iphmx.com Received: from esa2.mentor.iphmx.com (HELO esa2.mentor.iphmx.com) (68.232.141.98) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 14 Nov 2019 12:35:07 +0000 IronPort-SDR: TVnQb9Yg1mCZjmlAlp9RtnIZznr1+oXwSq6L+JUq1RPDBAswI++5KnBYVhd+ZHyJQViDFDaQOB +T0/sKZvMjVs/kqzyld7yaHRf+uXVGPMBMFN7LcXd9ev8oxpcn0KdJdRylFtTMQY6uJ2YZjDIv pIW50TybPFZP6vXbREdZhUKKlM2pT2rzBl+ktwBiVRAEKw+JlPFbtWzsMP5q9CNjc/pSHb2Dqm hTtf1Ta3r8PV5h7ItDqHQK9YZGHV5qKDpiGVPONrNmjdGqIRj7JRD1W34Avqbb4jlvID0vVbzX giE= Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 14 Nov 2019 04:34:31 -0800 IronPort-SDR: Tpb9IPhOjCuefkalP+bo4TQfdkkKfL43pmR8TuKzUFGRhza1Zhlge8HoyGDBCW7OE6t5b0qiya txNyQZPdgsDIz87wwWIuL3h/VgPp8E03wuwGalNvpNas2x03ayb6KugknOIJObrSevJ2tghoOs DSBxiq61Kg3vZ2sR0yv0N7Rr0NYyLbL/lgf26S3+3f97uhJ9CZ7DkRllkggxmwyhmsJ6Bow/Fz JozezvU0IsUqvC17vU02qJtfgvuDfAQr690ZQPjSNDvYHMOSSVNNHvmTlQt8EmrPlfp7o3FjRH 2fo= From: Kwok Cheung Yeung Subject: [PATCH] Check suitability of spill register for mode To: , Vladimir Makarov Message-ID: <110adf99-5023-0f74-e090-a6ebe72498b2@codesourcery.com> Date: Thu, 14 Nov 2019 12:34:13 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 Hello Currently, when choosing a spill register, GCC just picks the first available register in the register class returned by the TAQRGET_SPILL_CLASS hook that doesn't conflict. On AMD GCN this can cause problems as DImode values stored in SGPRs must start on an even register number and TImode values on a multiple of 4. This is enforced by defining TARGET_HARD_REGNO_MODE_OK to be false when this condition is not satisfied. However, assign_spill_hard_regs does not check TARGET_HARD_REGNO_MODE_OK, so it can assign an unsuitable hard register for the mode. I have fixed this by rejecting spill registers that do not satisfy TARGET_HARD_REGNO_MODE_OK for the largest mode of the spilt register. Built and tested for an AMD GCN target. This fixes failures in: gcc.dg/vect/no-scevccp-outer-9.c gcc.dg/vect/no-scevccp-outer-10.c I have also ensured that the code bootstraps on x86_64, though it currently does not use spill registers. Okay for trunk? Kwok 2019-11-14 Kwok Cheung Yeung gcc/ * lra-spills.c (assign_spill_hard_regs): Check that the spill register is suitable for the mode. --- gcc/lra-spills.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gcc/lra-spills.c b/gcc/lra-spills.c index 54f76cc..8fbd3a8 100644 --- a/gcc/lra-spills.c +++ b/gcc/lra-spills.c @@ -283,7 +283,8 @@ assign_spill_hard_regs (int *pseudo_regnos, int n) for (k = 0; k < spill_class_size; k++) { hard_regno = ira_class_hard_regs[spill_class][k]; - if (TEST_HARD_REG_BIT (eliminable_regset, hard_regno)) + if (TEST_HARD_REG_BIT (eliminable_regset, hard_regno) + || !targetm.hard_regno_mode_ok (hard_regno, mode)) continue; if (! overlaps_hard_reg_set_p (conflict_hard_regs, mode, hard_regno)) break;