From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) by sourceware.org (Postfix) with ESMTPS id 683AD3858D38 for ; Tue, 20 Jun 2023 05:00:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 683AD3858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-qt1-x82f.google.com with SMTP id d75a77b69052e-3fde82c8ca7so31159681cf.3 for ; Mon, 19 Jun 2023 22:00:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687237234; x=1689829234; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=QBlM9azkw2LvHevNLsH30Mw7tRQzHAalBhxdqCwsKkY=; b=ehgLmNkX9riu6N6iT654oZa/B/y7bmWqmzy2JQ8s8Atuw5rfctXt1Vw+gdzBYFIy5s rCr9Zcxw1Q/J2AiOSEPyeJ+Uc128StM9+9T2lF0ZSA0TLqteuEvj2mdMOLQG50Nx3h7r lCLkMIaAhcNSwp/CO8ttztNgDnwcSPpz8LuuyVxAxmTnIRcSecbZjzorjioTniQEiOJL BdIeYAjkS1iGPtcbPiFTBypqpEVTJc9wfWziWFDoi6zlrGhSm49rq6fKslEpmt4VGAsQ 5DGbGbXS3VEkdXKk+1Io8LF/pDRfZyVOoFeEbEk5CuqEjbNA+5Q6DSkdhI6lb0IBv0Vi +J6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687237234; x=1689829234; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=QBlM9azkw2LvHevNLsH30Mw7tRQzHAalBhxdqCwsKkY=; b=aR+L3lJqmkw+dEgUvPaQu4vuBXlxMLNrlQ1Kz39tzPZtvENqzn4RuN8npBwkkw0h6g ZnV4jukZesS6Bkayc6WUqHVpgxzd22hEDELAbS7/S0237u3wFuIvfejirC21qHnNQCnw uH5EeCLpy5kqzNlBY9G6hhGCHrOR3N0nwoJiGshaA5OO3NhShjh3RYFjoTHBr39U6xCx PkcVjcLJouFOLEM04btHaAx8YhCMNbhfrXHIHMAEG23FrvLBAdQ3pl4LYsX+YRqeaD5X vT/uQ9yTKR7FFxNLbG4r13ypGOBAwwzacru82bwCjyPeR6t4RynDhHmWFFWEr3U65l0d O2LA== X-Gm-Message-State: AC+VfDzsCLJ0TsBsdB8KPSl93ofF/vhn02r4pu1IniZkWwngh1avlQIE YiME8ItBzvivRdW+B613XHo= X-Google-Smtp-Source: ACHHUZ7cNviX23BVmXnu70rFnGStkHqi1u+PzBGjH40OWP6hDi/qOtka81VOj19HAKA+7/4+SzfOfQ== X-Received: by 2002:a05:622a:8b:b0:3fe:3074:64bc with SMTP id o11-20020a05622a008b00b003fe307464bcmr3989887qtw.10.1687237234195; Mon, 19 Jun 2023 22:00:34 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id s17-20020aa78d51000000b0065440a07294sm464198pfe.95.2023.06.19.22.00.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jun 2023 22:00:33 -0700 (PDT) Message-ID: <1a3e4d1e-59ee-c3ef-fd0b-d4d9265dc12d@gmail.com> Date: Mon, 19 Jun 2023 23:00:32 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH 2/2] cprop_hardreg: Enable propagation of the stack pointer if possible. Content-Language: en-US To: Tamar Christina , Andrew Pinski , Thiago Jung Bauermann Cc: Manolis Tsamis , Philipp Tomsich , Richard Biener , Palmer Dabbelt , Kito Cheng , "gcc-patches@gcc.gnu.org" References: <20230525123550.1072506-1-manolis.tsamis@vrull.eu> <20230525123550.1072506-3-manolis.tsamis@vrull.eu> <5836d561-2986-484c-8d9a-744c948e8602@gmail.com> <87ttv3xud1.fsf@linaro.org> <3bdd7695-ad88-d8d9-5133-05cb95623949@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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 List-Id: On 6/19/23 22:52, Tamar Christina wrote: >> It's a bit hackish, but could we reject the stack pointer for operand1 in the >> stack-tie? And if we do so, does it help? > > Yeah this one I had to defer until later this week to look at closer because what I'm > wondering about is whether the optimization should apply to frame related > RTX as well. > > Looking at the description of RTX_FRAME_RELATED_P that this optimization may > end up de-optimizing RISC targets by creating an offset that is larger than offset > which can be used from a SP making reload having to spill. i.e. sometimes the > move was explicitly done. So perhaps it should not apply it to > RTX_FRAME_RELATED_P in find_oldest_value_reg and copyprop_hardreg_forward_1? > > Other parts of this pass already seems to bail out in similar situations. So I needed to > write some testcases to check what would happen in these cases hence the deferral. > to later in the week. Rejecting for RTX_FRAME_RELATED_P would seem reasonable and probably better in general to me. The cases where we're looking to clean things up aren't really in the prologue/epilogue, but instead in the main body after register elimination has turned fp into sp + offset, thus making all kinds of things no longer valid. jeff