<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 12, 2020 at 6:22 PM Chen, Yuanfang via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This looks like per-function codegen pipeline. If there are existing cases of doing this, we could refer to these to implement it in an intuitive way. Overall, I think it is a bit overreaching and brings more downsides than benefits. If we do this per-TU during linking stage, could we read Module metadata and pass the flag to TargetPassConfig through TargetMachine::Options?<br></blockquote><div><br></div><div>Do you mean per-original-source-TU? That amounts to per-function under LTO (because LTO will merge functions from different TUs into one Module - so then parts of a Module will do one thing, and parts will do the other).<br><br>If you want to do it on a Module-level, Module-level metadata can be used. It supports merging/override, so if two front-end compilations asked for different things (one asked for GlobalISel, one asked to not have it) you could have a rule that either fails IR linking due to the conflict, or that picks one way or the other (GlobalISel overrides if any input has picked GlobalISel).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">________________________________________<br>
From: llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> on behalf of Amara Emerson via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
Sent: Tuesday, May 12, 2020 12:17 AM<br>
To: Quentin Colombet<br>
Cc: LLVM Developers' List; Matt Arsenault<br>
Subject: Re: [llvm-dev] Codegen pass configs dependent on function attributes?<br>
<br>
I’ve put up a patch here: <a href="https://reviews.llvm.org/D79769" rel="noreferrer" target="_blank">https://reviews.llvm.org/D79769</a> that adds a unified pipeline that targets can opt-into. It has some similarities with forcing fallbacks, but uses a different mechanism to do so to preserve the abort behavior. It therefore requires that every GISel pass needs to explicitly check whether the GISel selector is being requested rather than just using the FailedISel property.<br>
<br>
Cheers,<br>
Amara<br>
<br>
On May 5, 2020, at 6:56 PM, Quentin Colombet <<a href="mailto:qcolombet@apple.com" target="_blank">qcolombet@apple.com</a><mailto:<a href="mailto:qcolombet@apple.com" target="_blank">qcolombet@apple.com</a>>> wrote:<br>
<br>
Hi Amara,<br>
<br>
I’ve done that internally for testing purposes and basically the existing GISel pipeline with fallbacks just did what I wanted.<br>
In other words, I always used the GISel pipeline but I added an attribute that triggered a fallback to SDISel for the functions I wanted to compile with SDISel. I had to disable the global-isel-abort thing though. That said, that should be easily fixable.<br>
<br>
For the record, I was doing the attribute check in lowerFormalArgument IIRC. I.e., something that is called for every single function at the beginning of the GISel pipeline.<br>
<br>
Cheers,<br>
-Quentin<br>
<br>
On May 5, 2020, at 2:48 PM, Amara Emerson <<a href="mailto:aemerson@apple.com" target="_blank">aemerson@apple.com</a><mailto:<a href="mailto:aemerson@apple.com" target="_blank">aemerson@apple.com</a>>> wrote:<br>
<br>
Hi all.<br>
<br>
I’m trying to get GlobalISel to work better with LTO. At the moment if you enable it via -fglobal-isel, it only adds the -mllvm -global-isel and related options to the cc1 invocation. With LTO, that doesn’t work as we need to encode codegen options into the bitcode, usually via function attributes.<br>
<br>
Does anyone have any ideas on how to achieve this? The only way I can see it working is if we have a unified codegen pipeline for both GISel and SelectionDAG. Then use a function attribute to tell the GISel passes to skip and leave it to FastISel/SelectionDAG which runs afterwards. Likewise, FastISel/SelectionDAG would need to skip the function if it was marked for GISel compilation and we didn’t trigger a fallback.<br>
<br>
Amara<br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>