llvm dev - May 2020 - Codegen pass configs dependent on function attributes?

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

Hi Amara,

I’ve done that internally for testing purposes and basically the existing GISel
pipeline with fallbacks just did what I wanted.
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.

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.

Cheers,
-Quentin
> On May 5, 2020, at 2:48 PM, Amara Emerson <aemerson at apple.com>
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

I’ve put up a patch here: https://reviews.llvm.org/D79769
<https://reviews.llvm.org/D79769> 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.

Cheers,
Amara
> On May 5, 2020, at 6:56 PM, Quentin Colombet <qcolombet at apple.com>
wrote:
> 
> Hi Amara,
> 
> I’ve done that internally for testing purposes and basically the existing
GISel pipeline with fallbacks just did what I wanted.
> 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.
> 
> 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.
> 
> Cheers,
> -Quentin
> 
>> On May 5, 2020, at 2:48 PM, Amara Emerson <aemerson at apple.com>
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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200512/e04894f0/attachment.html>

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?

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200512/4ada7510/attachment.html>

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