[RFC] BasicAA considers address spaces?

Project Infrastructure LLVM Dev List Archives
21

From: "Hal Finkel via llvm-dev" <llvm-dev@lists.llvm.org>
To: "Daniel Berlin" <dberlin@dberlin.org>
Cc: llvm-dev@lists.llvm.org, "Justin Holewinski" <jholewinski@nvidia.com>
Sent: Wednesday, August 12, 2015 2:06:41 PM
Subject: Re: [llvm-dev] [RFC] BasicAA considers address spaces?

> From: "Daniel Berlin" <dberlin@dberlin.org>
> To: "Jingyue Wu" <jingyue@google.com>
> Cc: "Hal Finkel" <hfinkel@anl.gov>, llvm-dev@lists.llvm.org,
> "Justin Holewinski" <jholewinski@nvidia.com>
> Sent: Wednesday, August 12, 2015 2:03:34 PM
> Subject: Re: [llvm-dev] [RFC] BasicAA considers address spaces?
>
> SGTM

+1

Actually, upon further reflection, I don't we should create a new AA interface for this unless that's really necessary. AA passes can currently provide alias, pointsToConstantMemory, getArgModRefInfo, etc. and the target can quite reasonably want to enhance many of these.

Unless there's some reason why we can't, I think we should provide the target the ability to provide an AA analysis pass to be inserted in the chain, or maybe TTI should just *be* an AA pass that gets inserted into the chain?

-Hal

22

Then, we need to run this target-provided AA under -O3 to benefit the optimizations in O3.

I’m not sure what’s the best practice of doing this. One way is pass

  1. add a new interface TTI.getTargetAwareAliasAnalysis that returns the target-provided AA or nullptr
  2. Embed TTI in PassManagerBuilder
  3. When PassManagerBuilder::addInitialAliasAnalysisPass adds TTI.getTargetAwareAliasAnalysis to the pipeline.

Any better ideas?

23

So, the one downside of doing it this way is that the information
never will get to the other parts of the world.
We definitely don't want to go crazy and have tons of target-specific
alias info encoded into the AA interface.

I agree also, in general, this belongs in an AA pass and not the
interface (IE i don't think basicaa needs it).

However, for things like "memory spaces being disjoint", some other AA
passes may want to be able to know that.
IE If CFL-AA can tell that memory spaces are disjoint, it could avoid
unioning in stuff that can't really alias. Without such a hook, it
would be relegated to calling something like alias() on every pair :stuck_out_tongue:

So i'm torn on how best to make that happen, without people going off
and completely making things like basicaa super target-specific using
hooks (such that it ends up providing pretty crappy answers unless you
implement 60 different target hooks)

24

[+Chandler]

From: "Jingyue Wu" <jingyue@google.com>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: llvm-dev@lists.llvm.org, "Justin Holewinski" <jholewinski@nvidia.com>
Sent: Wednesday, August 12, 2015 3:39:52 PM
Subject: Re: [llvm-dev] [RFC] BasicAA considers address spaces?

Then, we need to run this target-provided AA under -O3 to benefit the
optimizations in O3.

I'm not sure what's the best practice of doing this. One way is pass
1) add a new interface TTI.getTargetAwareAliasAnalysis that returns
the target-provided AA or nullptr
2) Embed TTI in PassManagerBuilder
3) When PassManagerBuilder::addInitialAliasAnalysisPass adds
TTI.getTargetAwareAliasAnalysis to the pipeline.

Any better ideas?

I've cc'd Chandler so he can comment here.

Currently, TargetMachine can optionally return a TargetIRAnalysis object; this is then provided a function for which it can produce the actual TargetTransformInfo-derived object. TargetTransformInfoWrapperPass is the actual pass, and it just holds a pointer to the TargetIRAnalysis object.

In our case, we'd like to provide the target a way to add some AA pass to take advantage of target-specific knowledge regarding address spaces, intrinsics, and other IR constructs whose meaning is completely target specific. I'm not sure how well it fits into this model.

In addition, we have other use cases where targets want to add passes to handle target-specific things into the pipeline (⚙ D11782 RFC: Target-specific loop idiom recognition, for example, for doing target-specific loop-idiom recognition).

Plus, we already have a mechanism for allowing extension of the optimization pipeline, and I think the best way of approaching this (which is also useful for other use cases), is to provide the targets the ability to use this mechanism. I understand that this could be ripe for abuse (so we'd need to be vigilant in watching the targets), but nevertheless, how about this:

1. Add a function to TargetMachine called, for example, registerPassManagerBuilderExtensions(PassManagerBuilder *PMB). This would need to be called, for example, by the code in EmitAssemblyHelper in Clang in tools/clang/lib/CodeGen/BackendUtil.cpp (just as it currently calls TM->getTargetIRAnalysis() and so that it can call createTargetTransformInfoWrapperPass) and also registers other extensions itself.

2. registerPassManagerExtensions's job will be to call PassManagerBuilder::addExtension (or addGlobalExtension) as appropriate.

3. Create a new extension point for AA passes, and call addExtensionsToPM inside PassManagerBuilder::addInitialAliasAnalysisPasses

This will automatically cover a wide variety of use cases, including this one. Thoughts?

-Hal

25

From: "Daniel Berlin" <dberlin@dberlin.org>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: llvm-dev@lists.llvm.org, "Justin Holewinski" <jholewinski@nvidia.com>
Sent: Wednesday, August 12, 2015 4:36:54 PM
Subject: Re: [llvm-dev] [RFC] BasicAA considers address spaces?

So, the one downside of doing it this way is that the information
never will get to the other parts of the world.
We definitely don't want to go crazy and have tons of target-specific
alias info encoded into the AA interface.

I agree also, in general, this belongs in an AA pass and not the
interface (IE i don't think basicaa needs it).

However, for things like "memory spaces being disjoint", some other
AA
passes may want to be able to know that.
IE If CFL-AA can tell that memory spaces are disjoint, it could avoid
unioning in stuff that can't really alias. Without such a hook, it
would be relegated to calling something like alias() on every pair :stuck_out_tongue:

So i'm torn on how best to make that happen, without people going off
and completely making things like basicaa super target-specific using
hooks (such that it ends up providing pretty crappy answers unless
you
implement 60 different target hooks)

We might be able to consider address spaces somewhat special in this regard -- they're already somewhat special. Like target-specific intrinsics, they are an IR-level feature with target-defined semantics. As a result, I feel it would be justified to add some additional IR-level support to provide some more information to the generic IR analysis. We could, for example, use module-level metadata to encode address-space disjointness information, and that could be leveraged by BasicAA, etc.

This fits with the role of metadata, in that if the metadata were dropped, the IR analysis would simply fallback to making the same kinds of conservative decisions it makes now.

-Hal