[llvm-dev] Execute intrinsic lowering passes on demand
Florian Hahn via llvm-dev
llvm-dev at lists.llvm.org
Tue Mar 31 15:21:14 PDT 2020
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?
More information about the llvm-dev