llvm dev - Mar 2020 - Execute intrinsic lowering passes on demand

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.

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

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.

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?

Cheers,
Florian

On 3/31/20 5:21 PM, 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 think there isn't. At least for OpenMPOpt we have custom code to
determine if OpenMP runtime functions are present or not. If we end up
with some functionality that works for regular functions as well, I'd be
happy to use that instead.

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

This sounds interesting but we need to profile it. We could even be more
coarse-grained and record the creating of a class of intrinsic instead 
of its
presence in the module. That should be less overhead as it doesn't
affect non-intrinsic at all.


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

I have a bad feeling about this. If we consider it further I'll try to
find actual arguments.


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

As mentioned, I'd be interested in some infrastructure to check for the
presence of functions. Though that will not help compile time it.
For that we could potentially group lowering passes.


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

These are first thoughts, let's see where this leads.

Btw, thanks for reaching out on this!

Cheers,
   Johannes


 > Cheers,
 > Florian
 > _______________________________________________
 > LLVM Developers mailing list
 > llvm-dev at lists.llvm.org
 > https://lists.llvm.org/cgi-bin/mailman/listinfo/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