[llvm-dev] Execute intrinsic lowering passes on demand

[Johannes Doerfert via llvm-dev]

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