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

[David Blaikie via llvm-dev]

On Tue, May 12, 2020 at 6:22 PM Chen, Yuanfang via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

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

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

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


> ________________________________________
> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Amara
> Emerson via llvm-dev <llvm-dev at lists.llvm.org>
> Sent: Tuesday, May 12, 2020 12:17 AM
> To: Quentin Colombet
> Cc: LLVM Developers' List; Matt Arsenault
> Subject: Re: [llvm-dev] Codegen pass configs dependent on function
> attributes?
>
> I’ve put up a patch here: 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<mailto:
> 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<mailto:
> 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
>
>
> _______________________________________________
> 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/2e98b7ad/attachment.html>