[llvm-dev] Out-of-tree AA pass used from ModulePass

[Neil Henning via llvm-dev]

Hey Stephan,

Code is all closed-source secret-sauce, but here is how we register our AA
via the external AA callback:

struct Functor final
{
    Functor() = default;
    Functor(const Functor& other)
    {
        // We don't actually copy any of our analysis because they should
not have been initialized yet.
    }

    void operator()(llvm::Pass& pass, llvm::Function& function,
llvm::AAResults& aliasAnalysis)
    {
        // Add our Unity Burst Alias Analysis tracking.
        ubaaAliasAnalysis.invalidate(function);
        aliasAnalysis.addAAResult(ubaaAliasAnalysis);
    }

private:
    UBAAAliasAnalysis ubaaAliasAnalysis;
};

llvm::Pass* burst_CreateExtraAliasAnalysisLegacyPass()
{
    std::function<void(llvm::Pass&, llvm::Function&, llvm::AAResults&)>
func = Functor();
    return createExternalAAWrapperPass(func);
}

Hopefully that can help!

Cheers,
-Neil.

On Tue, Aug 17, 2021 at 7:03 PM Stephan Diestelhorst <stephand at xilinx.com>
wrote:

> Hi Neil,
>
> Thanks for the fast response, that looks like it is the right thing,
> however, I am still not getting my external AA pass invoked via the
> call-back.  There are a few things that I notice when looking at uses of
> llvm::LegacyAAGetter (in LLVM) vs my code:
>
> (1) Uses of it are usually wrapped in a function_ref<AAResults
> &(Function&)> which delays calling the functions, which I don’t know what
> it is used for
> (2) My code has a module pass querying another function pass result which
> in turn queries the AA pass
> (3) I am using the old-style of pass structure, instead of mixins
>
> Just for testing, I get rid of both (1) and (2) by simply calling
> LegacyAARResult(*this)(f).getModRefBehavior(<something>) from inside my
> ModulePass, but it does not get daisy chained to my MyAA / the call back
> registered with ExternalAAWrapper.  If I use the function_ref approach, I
> somehow get a segment violation (I think I don't understand some lifetime
> challenge here).
>
> Is the code you reference available somewhere for me to have a look or
> some other code that uses an external AA pass from the command line?  A
> quick look on GitHub didn't turn up too many (just a SCAF piece) results...
> otherwise, I will try to create a small example and post that here.
>
> Thanks,
>   Stephan
>
> From: Neil Henning <neil.henning at unity3d.com>
> Sent: 17 August 2021 08:27
> To: Stephan Diestelhorst <stephand at xilinx.com>
> Cc: llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] Out-of-tree AA pass used from ModulePass
>
> CAUTION: This message has originated from an External Source. Please use
> proper judgment and caution when opening attachments, clicking links, or
> responding to this email.
>
> Hey Stephan,
>
> To get function-level AA results in a ModulePass with the legacy pass
> manager you should use `llvm::LegacyAARGetter`. Because AA results are
> per-function, you call this with the function you want alias results about.
> That should get you any AA you registered with the external AA wrapper (we
> use the same mechanism in Unity's HPC# Burst compiler for instance).
>
> Cheers,
> -Neil.
>
> On Mon, Aug 16, 2021 at 10:46 PM Stephan Diestelhorst via llvm-dev <mailto:
> llvm-dev at lists.llvm.org> wrote:
> (Please keep me in CC, not sure my subscription request has made it
> through yet)
> Hi all,
>
> I am building a fairly extensive set of compiler passes out-of-tree with
> LLVM, and this all works nicely, except for tying my custom AA pass MyAA
> into the overall AA aggregator via AAResultsWrapper. As far as I can see,
> the ExternalAAWrapper does what I want and allows me to add an out-of-tree
> AA pass to the list of passes that is consulted when my other passes (let's
> say MyFuncPass) need an alias analysis result, by having registered a
> call-back in ExternalAAWrapper that will add MyAAResult into
> llvm::AAResult, which then gets consulted in AA queries if needed. This
> works for now (with some hacks).
>
> The problem is, however, when I convert MyFuncPass to a module pass, and I
> am then trying to get aa results for my functions.  The problem is that the
> call-back I registered (I see that happening!) with ExternalAAWrapper is
> never being run, so my AA results are not added to the mix.  I am using opt
> and the legacy pass managers, and I am struggling to understand how this
> should be used correctly, and why the call-back is not executed in time
> when turning my pass into a ModulePass.
>
> I am getting my aa results via
> getAnalysis<AAResultsWrapperPass>().getAAResults() in MyFuncPass, and with
> getAnalysis<AAResultsWrapperPass>(f).getAAResults() with f being the
> function I am currently looking into in the ModulePass.
>
> I am not really sure which passes I must specify with addRequired(..) or
> on the command line and it seems the documentation around AA in general and
> external AA specifically is somewhat outdated / sparse.
>
> Does this fairly high-level description ring any bells?  My code is pretty
> wild at this point, so it is not trivial to create a simple example, but I
> can do it if it would be helpful here.  Further, for various reasons
> (started this project a fair while ago) I am still on LLVM 8, but AFAICS,
> not much has changed in this area. That said, I don't have a great
> understanding how the whole (legacy) pass manager piece hangs together.
>
> Thanks,
>   Stephan
> --
> Stephan Diestelhorst
> System Architect
> Xilinx - Data Center Group
> Cambridge, UK
>
> This email and any attachments are intended for the sole use of the named
> recipient(s) and contain(s) confidential information that may be
> proprietary, privileged or copyrighted under applicable law. If you are not
> the intended recipient, do not read, copy, or forward this email message or
> any attachments. Delete this email message and any attachments immediately.
> _______________________________________________
> LLVM Developers mailing list
> mailto:llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> --
>
>
> Neil Henning
> Senior Software Engineer Compiler
> http://unity.com
>
>

-- 
Neil Henning
Senior Software Engineer Compiler
unity.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210818/c0a29ea2/attachment.html>