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

[David Blaikie via llvm-dev]

On Tue, May 12, 2020 at 3:51 PM Amara Emerson via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> 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.
>

There are a few options & examples of all of them:

* the data layout string
* function attributes
* mergeable (or overridable) llvm::Module metadata
* DICompileUnit flags (sort of like the debug info equivalent of function
attributes - persists through LTO/respected on a per-CU basis, etc)
* direct MC flags with no serialization

All of these exist and are used in some cases to implement various
user-facing flags. Working on debug info, I've seen more of the latter two
than anything else. But, by way of example, compressing DWARF isn't
something LLVM currently has support for on a per-function or per-CU basis,
it's either all on, or it's not. And at the time it was implemented we
didn't have as robust support for Module metadata - so it was implemented
as a straight up MC flag. If you want to compress your debug info, you need
to pass that flag to whatever command is actually the one making the native
object files. (it'll be ignored if you pass it to only the frontend compile
in an LTO build - you'd have to pass it to the link step, where real object
files are created)

But, yes, in /general/ there's a goal of "LTO should work the same as
non-LTO", so flags you'd usually pass to the source -> object command,
should be respected even when it produces an object that's really just an
llvm::Module, etc.

That's where function attributes and DICompileUnit flags go - so that LTO
can still respect the different choices of the original input compilations.
It's admirable, but not a hard line by any means I'm aware of.

If you think it's worth the effort to have it respected per-function, for
ease of debugging and the like - yeah, it's certainly an option!

>
> On Tue, May 5, 2020 at 5:48 PM Amara Emerson via llvm-dev <
> 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
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> 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/49b611c3/attachment.html>