[llvm-dev] Codegen pass configs dependent on function attributes?

[Amara Emerson via llvm-dev]

> On May 12, 2020, at 1:12 PM, James Y Knight <jyknight at google.com> wrote:
> 
> If you don't care about being able to select GlobalISel vs SDag separately per object file, it'd be a lot simpler to just also pass a flag to the linker, right?
I think being able to select per function would actually be a nice feature for debugging and bug reducing purposes. The real reason I tried to not go for a linker flag was because it would be an exceptional case just for GlobalISel. No other codegen option seems to rely on a linker flag (maybe I’m wrong here?). Passing it via bitcode just seemed the Right Thing To Do, even if it was a pain to implement.

If the consensus is that a one off linker flag for GlobalISel is the right way to go, then that’s ok with me.
> 
> On Tue, May 5, 2020 at 5:48 PM Amara Emerson via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Hi all.
> 
> 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.
> 
> 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.
> 
> Amara
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200512/a37e4979/attachment-0001.html>