From patchwork Mon Jan 7 14:42:44 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Andre Vieira (lists)" X-Patchwork-Id: 1021381 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-493538-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="qgTvPuiP"; 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 43YJ5s4cZkz9sDn for ; Tue, 8 Jan 2019 01:42:57 +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:to :from:subject:message-id:date:mime-version:content-type; q=dns; s=default; b=mH4g336L72Fqp0lAUbsO+n1gQ/BjZdZ1Y7U2wuvFM4EEFcvCY9 wydxic16eTVc11WSjnknYYR6DMJaKMqalt30yNwt7eOEMjeNAymjtQNyXCZRjiND hf/0MK71NFduXlNY5XgS2zTozwPHFCgTIhd/qhjP3C/fwHaBXe0LAL8NI= 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:to :from:subject:message-id:date:mime-version:content-type; s= default; bh=CebPdIPQ0Z83TSyIwQ+hd0eYqzY=; b=qgTvPuiPsVBY7/kVdT6o IUTP6X/5rsq+rKBElYUqvxv76P6bTVwrloBv6C5Qxdk+uudiMASi0tOaKqEqFy02 oYOl+p9qflZqfOZBLY8Npp7zmCFp8MUcUZCBb8GVzCel0rBh4ajezGrKU2QLc4f6 M4NIQBif89Cnxa+ZeoXqkog= Received: (qmail 63895 invoked by alias); 7 Jan 2019 14:42:50 -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 63886 invoked by uid 89); 7 Jan 2019 14:42:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_PASS autolearn=ham version=3.3.2 spammy=grab, quoting X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 07 Jan 2019 14:42:48 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DDAA780D for ; Mon, 7 Jan 2019 06:42:46 -0800 (PST) Received: from [10.2.207.62] (e107157-lin.cambridge.arm.com [10.2.207.62]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 861D53F5AF for ; Mon, 7 Jan 2019 06:42:46 -0800 (PST) To: gcc-patches@gcc.gnu.org From: "Andre Vieira (lists)" Subject: [PATCH, GCC] PR target/86487: fix the way 'uses_hard_regs_p' handles paradoxical subregs Message-ID: Date: Mon, 7 Jan 2019 14:42:44 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 X-IsSubscribed: yes Hi, This patch fixes the way 'uses_hard_regs_p' handles paradoxical subregs. The function is supposed to detect whether a register access of 'x' overlaps with 'set'. For SUBREGs it should check whether any of the full multi-register overlaps with 'set'. The former behavior used to grab the widest mode of the inner/outer registers of a SUBREG and the inner register, and check all registers from the inner-register onwards for the given width. For normal SUBREGS this gives you the full register, for paradoxical SUBREGS however it may give you the wrong set of registers if the index is not the first of the multi-register set. The original error reported in PR target/86487 can no longer be reproduced with the given test, this was due to an unrelated code-gen change, regardless I believe this should still be fixed as it is simply wrong behavior by uses_hard_regs_p which may be triggered by a different test-case or by future changes to the compiler. Also it is useful to point out that this isn't actually a 'target' issue as this code could potentially hit any other target using paradoxical SUBREGS. Should I change the Bugzilla ticket to reflect this is actually a target agnostic issue in RTL? There is a gotcha here, I don't know what would happen if you hit the cases of get_hard_regno where it would return -1, quoting the comment above that function "If X is not a register or a subreg of a register, return -1." though I think if we are hitting this then things must have gone wrong before? Bootstrapped on aarch64, arm and x86, no regressions. Is this OK for trunk? gcc/ChangeLog: 2019-01-07 Andre Vieira PR target/86487 * lra-constraints.c(uses_hard_regs_p): Fix handling of paradoxical SUBREGS. diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c index c061093ed699620afe2dfda60d58066d6967523a..736b084acc552b75ff4d369b6584bc9ab422e21b 100644 --- a/gcc/lra-constraints.c +++ b/gcc/lra-constraints.c @@ -1761,11 +1761,21 @@ uses_hard_regs_p (rtx x, HARD_REG_SET set) return false; code = GET_CODE (x); mode = GET_MODE (x); + if (code == SUBREG) { + /* For all SUBREGs we want to check whether the full multi-register + overlaps the set. For normal SUBREGs this means 'get_hard_regno' of + the inner register, for paradoxical SUBREGs this means the + 'get_hard_regno' of the full SUBREG and for complete SUBREGs either is + fine. Use the wider mode for all cases. */ + rtx subreg = SUBREG_REG (x); mode = wider_subreg_mode (x); - x = SUBREG_REG (x); - code = GET_CODE (x); + if (mode == GET_MODE (subreg)) + { + x = subreg; + code = GET_CODE (x); + } } if (REG_P (x))