From patchwork Mon Jan 15 15:26:48 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Makarov X-Patchwork-Id: 84129 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9C531385840A for ; Mon, 15 Jan 2024 15:27:23 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 6FDF13858D1E for ; Mon, 15 Jan 2024 15:26:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6FDF13858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6FDF13858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705332415; cv=none; b=qvI0rtwX4yv7ZmXIIKStOcJQJD43howooGXhOq8zdR3AKcZtMzB2e6gki5yTiD6oUwx8e4JfR/T6DOZToGL1CMLjryB9X+CVam0YF8DTwiXfj5qtHDyP8mqW0CeXrGYx5ObV9V8YplAi6blIk8HtURjUtscY6EC/rZdhjnmlymM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705332415; c=relaxed/simple; bh=jeYaCVFgk4I9vq7vW7ZqhwtJJfM1SC9iZXdu+TrAqKA=; h=DKIM-Signature:Message-ID:Date:MIME-Version:To:From:Subject; b=YMNdsqE5dh2tgZNIwaio9w6NL3qnrONaiwoIHJhnWY6/4W+zJ1+BoZWjO3zkRpL7HD3tqPhzoXxAMaKV1XTl6n5woqyU+lvgykn7b+xHcLop40R9gO9AeKKhsuz2SpHVTL8pdgDlweiPXl8S4XNVDamxvUy9/xbWSuiAvVEV+kM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1705332413; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=ie7hTNoHU/19tcErDdsJ0CNx29rzwN22BQ1wSpqGrXk=; b=Fy5RbU20PiBOh0pZL5sdEKgI4f0LZenronW6+sv7mW86LhTOwyaXEM8IFAjHtLymxDv+cF +u76NOKadm6+xUQaJBBCpcAwre8Cf7gG6Un2BWibep5OUIJCEE2BAeMRwqHX33yTJd2y5A NI4W/1TCe5GbOEgN6uu1Q0Zvn5KLIfY= Received: from mail-ot1-f70.google.com (mail-ot1-f70.google.com [209.85.210.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-3-LPE0N7S6NVu86CjfxmTtDw-1; Mon, 15 Jan 2024 10:26:51 -0500 X-MC-Unique: LPE0N7S6NVu86CjfxmTtDw-1 Received: by mail-ot1-f70.google.com with SMTP id 46e09a7af769-6ddf165f956so9126206a34.2 for ; Mon, 15 Jan 2024 07:26:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705332410; x=1705937210; h=subject:from:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BmA0Qz2NH3F9K3gBtl+MKfu2QH9w10oSZw6RZWexB2g=; b=Xap4G0ykBIQ5oLzGvhOtqGs/vgdutX6+nFCsGZ1nshha+WQyOnPjNO7r1If72BQmCw ZBgPRJvBXxsuJmzYJ3RD6SQ2UjrefBxNtfnQEPUMwl12PsAS+PMs8/QS5mvs98AybJKe FtQeehh0MV5fgYiK66DmAeCgkQwWfd0w0z+fBuhwbXD4M6k8BJLlrstnhYcPhS2KD0+9 BMvfemNgZEoVQSy+3yoeEsu/sdX1aOObHjgLHAc9jjtefBm0jeAUyUzVRwsps67fmCBb ltTLQKKCitYyZ/D2U6dbBqZgGRkuVqwxEijuHgq5lLEg63kbLGLbk+hwG1qYww5vmlk/ lh0w== X-Gm-Message-State: AOJu0YxsmcHGGERfrwFTP8BUm7YE+TKZnul5NQPBcmhPa8HvO6K7wHml jcAskfYfPDJPrE0AT2lHQhmyygj4a2zchqdrHnXTg7tkOCyxA0CCly6PwSrMGJLKJj135oXCK/T s0Vm7BcX1YwI1uJPpjjGPW9Mo/a3q4Z4CjJ4nMMO1YUkhzx5bgbOr5XpVmdJ6tc3PUJmri42t2I wNmJ+RO+ti6A== X-Received: by 2002:a9d:7355:0:b0:6dd:eb93:5b20 with SMTP id l21-20020a9d7355000000b006ddeb935b20mr7787060otk.21.1705332409892; Mon, 15 Jan 2024 07:26:49 -0800 (PST) X-Google-Smtp-Source: AGHT+IG94vF+48cODl1lMHQRR/zXYQF4LYaFKXJOzgMFywfN6zfzBG9Xz+BaIUi7ddS2dsdpr+GOYw== X-Received: by 2002:a9d:7355:0:b0:6dd:eb93:5b20 with SMTP id l21-20020a9d7355000000b006ddeb935b20mr7787053otk.21.1705332409537; Mon, 15 Jan 2024 07:26:49 -0800 (PST) Received: from [192.168.1.88] (23-233-12-249.cpe.pppoe.ca. [23.233.12.249]) by smtp.gmail.com with ESMTPSA id ph4-20020a0562144a4400b006815ec86ab3sm920678qvb.46.2024.01.15.07.26.48 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Jan 2024 07:26:49 -0800 (PST) Message-ID: <2719a083-baca-3671-7a49-e7796d68adfb@redhat.com> Date: Mon, 15 Jan 2024 10:26:48 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 To: "gcc-patches@gcc.gnu.org" From: Vladimir Makarov Subject: [pushed][PR113354][LRA]: Fixing LRA failure on building MIPS GCC X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US X-Spam-Status: No, score=-11.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, RCVD_IN_SORBS_WEB, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org The following patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113354 The patch was tested on building MIPS target. The patch was successfully tested and bootstrapped on x86-64, ppc64le, aarch64. commit 5f662bce28618ea5417f68a17d5c2d34b052ecb2 Author: Vladimir N. Makarov Date: Mon Jan 15 10:19:39 2024 -0500 [PR113354][LRA]: Fixing LRA failure on building MIPS GCC My recent patch for PR112918 triggered a hidden bug in LRA on MIPS. A pseudo is matched to a register constraint and assigned to a hard registers at the first constraint sub-pass but later it is matched to X constraint. Keeping this pseudo in the register (MD0) prevents to use the same register for another pseudo in the insn and this results in LRA failure. The patch fixes this by spilling the pseudo at the constraint subpass when the chosen alternative constraint not require hard register anymore. gcc/ChangeLog: PR middle-end/113354 * lra-constraints.cc (curr_insn_transform): Spill pseudo only used in the insn if the corresponding operand does not require hard register anymore. diff --git a/gcc/lra-constraints.cc b/gcc/lra-constraints.cc index dc41bc3d6c6..3379b88ff22 100644 --- a/gcc/lra-constraints.cc +++ b/gcc/lra-constraints.cc @@ -4491,23 +4491,18 @@ curr_insn_transform (bool check_only_p) { if (goal_alt[i] == NO_REGS && REG_P (op) - /* When we assign NO_REGS it means that we will not - assign a hard register to the scratch pseudo by - assigment pass and the scratch pseudo will be - spilled. Spilled scratch pseudos are transformed - back to scratches at the LRA end. */ - && ira_former_scratch_operand_p (curr_insn, i) - && ira_former_scratch_p (REGNO (op))) + && (regno = REGNO (op)) >= FIRST_PSEUDO_REGISTER + /* We assigned a hard register to the pseudo in the past but now + decided to spill it for the insn. If the pseudo is used only + in this insn, it is better to spill it here as we free hard + registers for other pseudos referenced in the insn. The most + common case of this is a scratch register which will be + transformed to scratch back at the end of LRA. */ + && lra_get_regno_hard_regno (regno) >= 0 + && bitmap_single_bit_set_p (&lra_reg_info[regno].insn_bitmap)) { - int regno = REGNO (op); lra_change_class (regno, NO_REGS, " Change to", true); - if (lra_get_regno_hard_regno (regno) >= 0) - /* We don't have to mark all insn affected by the - spilled pseudo as there is only one such insn, the - current one. */ - reg_renumber[regno] = -1; - lra_assert (bitmap_single_bit_set_p - (&lra_reg_info[REGNO (op)].insn_bitmap)); + reg_renumber[regno] = -1; } /* We can do an optional reload. If the pseudo got a hard reg, we might improve the code through inheritance. If