From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) by sourceware.org (Postfix) with ESMTPS id 9EAA53852208 for ; Fri, 18 Nov 2022 16:42:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9EAA53852208 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-pg1-x52d.google.com with SMTP id r18so5419500pgr.12 for ; Fri, 18 Nov 2022 08:42:45 -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=zEPEpGs/XZX0/a2G5/M6wUv2SvrS4srYeTTOMjIHFFc=; b=QbnXZBPZEbjJn8vArjEPdeJPbQTB+2hYH4yhRVvXVGLYJaI7Qx68raOl4V21r1G6T+ tkZpRI3yALY8wtfUt5PoWaPuCvpuecx2e3b1i3loGR7nO1gXifNxXc2thfxwrYER1q8d 56e4lhAQIG2ibguuHqWeCSYqABaEogmhy8IqLIetsuc+O9fOHGldrS0kPWStFpv1I9hg kHAKcynPTgei+i2bJ7Bf4WhnKqgzNBr8/PvJgy11vVXA6iUmHghWRL6LmjfLhwT/yUl2 By/XIZLR0RGIT9Y5Bdlh0EUo4GAzck6pycnGLEJq9Pb/etQ8uO4WCV29ocg/Zi/vwFNF ECtQ== 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=zEPEpGs/XZX0/a2G5/M6wUv2SvrS4srYeTTOMjIHFFc=; b=DLGlL5CaZZjV5o8sBD7b2vsqqHat/27NXJRKGdD7nsdTLI39OQuiuj8vAblp/ohXBn H8uGFjTqB6Mzcmc1C4BSZEBXsPsUHtcRYAiDPHOolYlwsabjRUqNt0QRc0klexvfbMzs rkpv7Ob0HZcYcTZ3oE10ksWmP45YJhvWsDYsZ5csM7H5hGvbBZ4QJkTQiijOAr8e7kX4 O/uaKvKoT89ZQQC9vcXd0bNOkACOAaVPatYE06TKWwkvtXvhL7wPDxzw9DuYqeXGMQsJ C70rsSgMFhp6SwGmdqe2uopS/4/ejWYiqHYWtL0B6Y3m4uFL7PA+kfepH683jFwERHxC bglw== X-Gm-Message-State: ANoB5pnSXDEAVEs96Vzz2RdQRyCSQYOd3wjJArFSPlpfDMaFUTVuMC6J mKTCUbVsHY30c8VZL4jT1ylmV3QppJM= X-Google-Smtp-Source: AA0mqf6zmFK/JF1jeWPCFtLqJPJJ8bpnI297dpDPnvA3Wf+L80CS6NGc25SbgZUBWqtbfj71wr7+SA== X-Received: by 2002:a63:1f1d:0:b0:474:66fb:41fa with SMTP id f29-20020a631f1d000000b0047466fb41famr7188075pgf.21.1668789763892; Fri, 18 Nov 2022 08:42:43 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id ik28-20020a170902ab1c00b00186c41bd213sm3866212plb.177.2022.11.18.08.42.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Nov 2022 08:42:43 -0800 (PST) Message-ID: Date: Fri, 18 Nov 2022 09:42:41 -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: Jeff Law via Gcc-patches , 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/18/22 08:18, Richard Sandiford wrote: > > Yeah, good point. How does the version below look? Tested as before. > > I guess it's a philosophical question what distinguishes "late compilation" > from everything else, but I think it makes sense for it to mean "no code > motion" (among other things). And it's useful if targets have a well- > defined point at which they can insert their own passes while guaranteeing > that: > > - the CFG still exists and hasn't lost information > - no code motion occurs later > - alignments aren't nailed down yet > - variable tracking occurs later (and so will account for whatever the > target does in its pass) Seems like a reasonable set of properties.  Do we want to document this somewhere so that it get captured?  That can be independent of this particular patch. > > I don't think it's controversial to say that delay-branch reorg should > happen as part of normal scheduling, with the later passes coping with > the SEQUENCEs generated from it, but there's no realistic chance of > that happening. So unfortunately it's always likely to be a special > case... I've been wanting the guts of dbr moved into sched2 for a long time.  I've speculated that we could use the dependence analysis from sched2 to provide the candidates for delay slot filling and that doing so would probably pick up the vast majority of opportunities, but without the ad-hoc dependency bits in reorg.c. But yea, realistically nobody's going to invest the time to revamp reorg. > > Bernd did some nice work on avoiding dbr for bfin (IIRC), but without > the handling of SEQUENCEs in rtl passes, even that version had to > happen during md_reorg. Never really looked at it. > > Thanks, > Richard > > > gcc/ > * target.def (use_late_prologue_epilogue): New hook. > * doc/tm.texi.in: Add TARGET_USE_LATE_PROLOGUE_EPILOGUE. > * doc/tm.texi: 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. OK jeff