[llvm-dev] Execute intrinsic lowering passes on demand

[Simon Moll via llvm-dev]

Hi Florian,

i am particularly interested in this as i am working on the llvm.vp.* 
lowering pass. That pass will lower VP intrinsics to standard
instructions but also other intrinsics, which again may be lowered (eg
llvm.*.vector.reduce.*).

On 4/1/20 12:21 AM, Florian Hahn via llvm-dev wrote:
> Hi,
>
> Currently there are quite a few passes that lower various intrinsics and those are usually executed unconditionally. Usually they iterate over all functions in a module.
>
> I am working towards enabling the lowering pass for matrix intrinsics unconditionally as well, but ideally it should only run if there are some matrix intrinsics present. It looks like currently there is no standard way to check whether a function/module contains code that calls certain (overloaded) intrinsics.
>
> I explored a few options to avoid (some) unnecessary runs of various lowering passes and I would they appreciate any thoughts on the different approaches, as they have different benefits and drawbacks.
>
> 1. Extend Module to allow checking if there are any declarations for a given overloaded intrinsics.
> Lowering passes would then check if there are any declarations for any of the intrinsics they want to lower and only run if there are. The key is dealing with overloaded intrinsics. We would have maintain a set of intrinsic IDs declared in the module or something similar. That could be done by adding addNodeToList/removeNodeFromList callbacks for the list of functions.

Independent of whether we add infrastructure to track the presence of
calls to certain functions: why not create an intrinsic/function
indexing analysis that sweeps over the module exactly once(*). The
various lowering passes could then ask that analysis for all intrinsics
(' calls) they are interested in. The efficiency of that scheme clearly
depends on whether all lowering passes are grouped together (codegen
prepare), in which case the analysis would run only once, or spread out
over the pass pipeline, in which case the analysis would have to re-run
before each cluster of lowering passes.

*: if tracking infrastructure were added the indexing pass could
leverage while the actual lowering passes wouldn't need to change.

> 2. Make running a lowering pass conditional on a function attribute.
> Require frontends/passes that add calls to certain intrinsics to mark functions as containing such intrinsics via a function attribute. The lowering passes would only run on functions with the correspond attributes (e.g. add a may-contain-matrix-intrinsics attribute and only run matrix lowering on functions with that attribute).
Siding with Johannes here, not sure whether an attribute would be the
right thing for this. Clearly, you could query for the
may-contain-matrix-intrinsics attribute if we had an indexing pass.
> 3. Continue running lowering passes unconditionally
> Probably not a very big deal in terms of compile-time, until we reach a certain number of lowering passes.
This might happen rather sooner than later given that both of us are
working on such passes right now ;-)
> Out of the options, 1. would probably be easiest to adapt for existing lowering passes. While being a bit more coarse-grained, it should still allow us to skip lowering passes in a large range of cases. Across MultiSource, SPEC2000 & SPEC2006 it allows skipping ~90% of the runs of LowerConstantIntrinsics and LowerExpectIntrinsic for example. 2. should be easy to adapt for new lowering passes/intrinsics, but might be more tricky for existing lowering passes/intrinsics, if we only rely on the frontends to add the attributes. Alternatively we could run a lightweight pass that adds the attribute up-front for existing lowering passes. The overall gain would probably be limited then, until all frontends emit the required attributes.
>
> I’d appreciate any thoughts on the different approaches. Is there an even better way to tackle the problem?

Thanks for bringing this up!

Simon

>
> Cheers,
> Florian