[llvm-dev] Multi-Threading Compilers

Chris Lattner via llvm-dev llvm-dev at lists.llvm.org
Wed Mar 25 13:27:33 PDT 2020

> On Mar 25, 2020, at 8:35 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
> MLIR distinguishes between "attributes" and "operations". So you'd
> define a constant by placing an operation (aka instruction) in each
> function that has the actual constant as an attribute.
> mlir::Attributes don't have use lists at all, so they're like
> llvm::Metadata in that sense.

FWIW, the Swift SIL IR does the same thing - it uses “integer_literal” instructions to materialize constants.  In addition to the multithreading benefits explored in this thread, this also allows carrying location information more correctly.  This is important for source level analysis tools, debugging etc.

> There is a certain elegance to having explicit instructions to import
> constants into the llvm::Function context, but also ugliness, as IR
> will then be full of "constant" instructions, unlike today. Plus,
> changing all existing LLVM IR to have those is an enormous amount of
> churn.

Yes, it increases verbosity of the IR this is very true. In practice, it is not a problem though.

> I'm not totally opposed to doing this, but I'd lean towards
> smaller, incremental steps.
> Regardless, there are some related cleanups that seem like they would
> be useful. For example, getting rid of llvm::ConstantExpr seems like a
> very good idea to me, though somewhat orthogonal to the problem of
> multi-threading. While we're at it, we could get rid of
> llvm::ConstantAggregate and move llvm::Constant to no longer be an
> llvm::User. This may impact how global value initializers work.

I would love to kill off ConstantExpr.  It is a huge design wart: for example the fact that we have constantexpr “divide” instructions means that constants “canTrap()” which leads to all sorts of problems.

A much better design (ignoring the multithreading concerns) would be to make scalar constants be llvm::Constant’s, keep aggregate constants but only allow them in global variables, and introduce a new ConstantExpr like class which represents a linker-relocatable expressions like “symbol+constant” and “symbol1-symbol2+constant” on Darwin.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200325/b598f062/attachment.html>

More information about the llvm-dev mailing list