From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by sourceware.org (Postfix) with ESMTPS id 93A9238A8168 for ; Tue, 15 Nov 2022 17:57:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 93A9238A8168 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-pj1-x1034.google.com with SMTP id d13-20020a17090a3b0d00b00213519dfe4aso14568289pjc.2 for ; Tue, 15 Nov 2022 09:57:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=RJUFV0a86xrSLI09XIjwSPTUmj+P6P0aegSimvoKpIU=; b=Xg/VSJV2Yg1nyaHhpJUoTDsKOWQMg1h3zoX3JeOGm8086BjkORqbKfjyjbZ+FLbyyV Hx8H/xN+rrgBmPKdhpeWUb8ciWtRgbacGamT9fTTaQGARtuzCmjlq9oG4Zvqcv/KHo5n YKjpC/I+dqQaY9hVZh1O0XPNc+OLRcoi3l+3JgKM5vNn09C4m6ul94WfJeAtl+U3cEx9 Pzo4wy1RxvhMBmZ3RSmHiVm3jrCabLNiM2WKMCZj3EXRXVl6M1ZgMSLeAZ+DN5dkVf0h AIOAXyOiPLcP7mpm0gxGV10zM96QMbonogsn6JXPGUbFNjZ/bCsUc4i75eC7pL/dIqm9 B+Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references: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=RJUFV0a86xrSLI09XIjwSPTUmj+P6P0aegSimvoKpIU=; b=asgRu+bDvf/+hc1CJl+sSaH7ydL3607+eVtDgvfZse9/ZyDS7CT47w5zgiRrgfxgm7 Yr6fVz/rUJO9End092kKNMsCEdJSreZDDv4mbKyElWi1xMLmp/O0lncQWxN+2ljbCaOi rkJmdeuL41bTvAADEB8wkM2xcZ1QYg9hHqOY+OzxygDve3koIcaJfk7EspYL8bvumg9u 68QQPcqCas4dFAPGySxIZyv6ymUKt6+I1IJZIWCatNwb95Ch448bZURVn6fVit04thiL 9hjeCRsOAMK10SmGVOys0FhX1x2jCoel7jLbOrUOFupCdy/IYnkSeaGC1P0HCFlsdY6M PC3A== X-Gm-Message-State: ANoB5pkJ1ef9XZ7gjFhZtU1WQCcMBWpHvIRI8BDwQ1cvNmC/3bhUkyHD Id6V6tp0s2cDx1p6VrBKBizstQRs2mY= X-Google-Smtp-Source: AA0mqf7aylCT7UqvFWaj1I1F5+VddwlDhOCLc/+wq/3wvV48lZonARSLPApwhtCstZwUQUY5Nj1otQ== X-Received: by 2002:a17:902:db0a:b0:17c:7aaa:c67d with SMTP id m10-20020a170902db0a00b0017c7aaac67dmr4975450plx.171.1668535039800; Tue, 15 Nov 2022 09:57:19 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id 68-20020a620447000000b0056b9df2a15esm1583743pfe.62.2022.11.15.09.57.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Nov 2022 09:57:18 -0800 (PST) Message-ID: Date: Tue, 15 Nov 2022 10:57:17 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH] Allow prologues and epilogues to be inserted later Content-Language: en-US To: gcc-patches@gcc.gnu.org, richard.sandiford@arm.com References: From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.5 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 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 11/11/22 09:21, Richard Sandiford via Gcc-patches wrote: > Arm's SME adds a new processor mode called streaming mode. > This mode enables some new (matrix-oriented) instructions and > disables several existing groups of instructions, such as most > Advanced SIMD vector instructions and a much smaller set of SVE > instructions. It can also change the current vector length. > > There are instructions to switch in and out of streaming mode. > However, their effect on the ISA and vector length can't be represented > directly in RTL, so they need to be emitted late in the pass pipeline, > close to md_reorg. > > It's sometimes the responsibility of the prologue and epilogue to > switch modes, which means we need to emit the prologue and epilogue > sequences late as well. (This loses shrink-wrapping and scheduling > opportunities, but that's a price worth paying.) > > This patch therefore adds a target hook for forcing prologue > and epilogue insertion to happen later in the pipeline. > > Tested on aarch64-linux-gnu (including with a follow-on patch) > and x86_64-linux-gnu. OK to install? > I'll ob > Richard > > > gcc/ > * target.def (use_late_prologue_epilogue): New hook. > * doc/gccint/target-macros/miscellaneous-parameters.rst: Add > TARGET_USE_LATE_PROLOGUE_EPILOGUE. > * doc/gccint/target-macros/tm.rst.in: Regenerate. > * passes.def (pass_late_thread_prologue_and_epilogue): New pass. > * tree-pass.h (make_pass_late_thread_prologue_and_epilogue): Declare. > * function.cc (pass_thread_prologue_and_epilogue::gate): New function. > (pass_data_late_thread_prologue_and_epilogue): New pass variable. > (pass_late_thread_prologue_and_epilogue): New pass class. > (make_pass_late_thread_prologue_and_epilogue): New function. I'm not sure how we'll enforce the no target independent code motion limitation that this seems to need and the exception made for reorg is hackish in that it appears we just rely on the fact that reorg isn't run for the one target where this matters.  That does make me wonder if we should future proof this ever so slightly -- is there a reasonably easy way to fail if a target were to define delay slots and the need for late prologue/epilogue?  If so, that seems advisable. No objection to the meat of the patch, just wondering a bit about the additional sanity checking we can do... Jeff