From patchwork Tue Nov 22 23:20:58 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jeff Law X-Patchwork-Id: 60995 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 6C1783854557 for ; Tue, 22 Nov 2022 23:21:21 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by sourceware.org (Postfix) with ESMTPS id CFAB43854555 for ; Tue, 22 Nov 2022 23:21:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CFAB43854555 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ventanamicro.com Received: by mail-pj1-x102b.google.com with SMTP id o5-20020a17090a678500b00218cd5a21c9so308522pjj.4 for ; Tue, 22 Nov 2022 15:21:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; h=subject:from:to:content-language:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=WeLQ/rhBvYIDu2b2q58UFmGTY+g70kAwzJKXQL+H0IM=; b=dWVllPxvvqhycKq/ONg3aNbhPIVyOqywRYwgONmSStaUQd0Uh5VtZ5Rgzx5P+S4RTf lQGHH/v9gqx+zVJdYUBg0jHlDu5zdSP21jwfjTpeu37A/vmiNm0KzlHDa9l6oS1Udx11 daG+QZH5iWrfwRxJkK6uZrppo3He/9vxqNn9nKZiH3ZAcDBB63pSjU5S+gZpKEcjWe2T l0HdSgmWT0Q60yrQoa7vSl5rluAY4RZN3Xj55tFjIkXjUyY7wu326MIsObJZrTuGORAc jyp0fUvby8Mhi5J4BYOA7Ae1/7stPEvktmW3GsbGMcZpjaXl8yg7FxzBYuWvEa2VB8aQ 9LTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=WeLQ/rhBvYIDu2b2q58UFmGTY+g70kAwzJKXQL+H0IM=; b=vlnAZGyLhf2PyHb3xXR9iqMYKUUxuX3zPOmvHNiX+EgfZRoguLoqmIcVKBcQutpVTF OTFCIxewc9ubPJCZPWKT02ddAe/7Z0Qwq41+jHth7tuaUTlhZSKfT1MLal8r8Jux0IUa UepCHz5Cm+NE2xeL0vAAD0obydRhCUS1niVM1D7Zlgjvb4wZpimt/OpAdR+JuUSANPm3 2Ayrysa8sSNYws8IUWk/vp990ggf7W6o55D6ykM14ZXv9/Kv8S+a9793ioE4QiD+dnbT 4z9gYeTNVBtkw2lgxKuQZHaImkpS3v4scEgVu+PqZe+oBoj0BEc54B83gal6MYONw/Hb ZgTA== X-Gm-Message-State: ANoB5plSUpn1nbxOerH+NkSuJmk3Ck4q8EaTf/jdGwtAJ76Xj++Nvp7d +je85+AQo5FpYL09B5zIpybBEUOSTpq8RA== X-Google-Smtp-Source: AA0mqf6acHT3+T4hodlRkYvwA6jyMMCwaG7JYVUenBwDV8aG3dgeKMOF4s1QnAJYPwc6g5TqtwJIyQ== X-Received: by 2002:a17:90a:fd87:b0:218:d86a:375b with SMTP id cx7-20020a17090afd8700b00218d86a375bmr3004736pjb.57.1669159260637; Tue, 22 Nov 2022 15:21:00 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::99f? ([2601:681:8600:13d0::99f]) by smtp.gmail.com with ESMTPSA id h11-20020aa796cb000000b0056c3a0dc65fsm11193521pfq.71.2022.11.22.15.20.59 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Nov 2022 15:21:00 -0800 (PST) Message-ID: <293c6900-a6b8-9bcb-9752-5f41554e80c5@ventanamicro.com> Date: Tue, 22 Nov 2022 16:20:58 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Content-Language: en-US To: "gcc-patches@gcc.gnu.org" From: Jeff Law Subject: [committed][RISC-V] Fix recent rvv/base/spill testcase failures X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP 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.29 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 Sender: "Gcc-patches" As Jaiwei noted, many (all?) of the rvv/base/spill tests started failing after the introduction of shrink-wrapping. The core issue is we're expecting the frame to have a constant size, but it doesn't.  So when using the to_constant method we abort. The safest thing to do is to set no shrink-wrapping components when the frame size is not fixed.  We might be able to do better later -- iff we know the offset to the GPRs/FPRs is fixed and fits into the appropriate number of bits. Bootstrapped and regression tested (C-only) on riscv64-linux-gnu.  As expected, it fixes a bucketload of failures in rvv/base/spill-*.c. Installed on the trunk, Jeff commit ca73d4c80ea06087d9dd22594e5670bb15e21066 Author: Jeff Law Date: Tue Nov 22 18:12:45 2022 -0500 Fix recent rvv/base/spill testcase failures he core issue is we're expecting the frame to have a constant size, but it doesn't. So when using the to_constant method we abort. The safest thing to do is to set no shrink-wrapping components when the frame size is not fixed. We might be able to do better later -- iff we know the offset to the GPRs/FPRs is fixed and fits into the appropriate number of bits. Bootstrapped and regression tested (C-only) on riscv64-linux-gnu. As expected, it fixes a bucketload of failures in rvv/base/spill-*.c. gcc/ * config/riscv/riscv.cc (riscv_get_separate_components): Do not do shrink-wrapping for a frame with a variable size. diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc index 7ec4ce97e6c..7bfc0e9f595 100644 --- a/gcc/config/riscv/riscv.cc +++ b/gcc/config/riscv/riscv.cc @@ -5340,7 +5340,8 @@ riscv_get_separate_components (void) bitmap_clear (components); if (riscv_use_save_libcall (&cfun->machine->frame) - || cfun->machine->interrupt_handler_p) + || cfun->machine->interrupt_handler_p + || !cfun->machine->frame.gp_sp_offset.is_constant ()) return components; offset = cfun->machine->frame.gp_sp_offset.to_constant ();