[llvm-dev] Multi-Threading Compilers

[Owen Anderson via llvm-dev]

> On Thu, Mar 26, 2020 at 12:47 AM Chris Lattner <clattner at nondot.org> wrote:
>>> 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.
> 
> Okay, it seems like it could be a viable long-term goal to do this.
> What I'm trying to figure out is how to incrementally evolve LLVM IR,
> and it feels like this change to enable "constant materialization
> instructions" is extremely invasive in terms of churn in the code base
> on a level comparable to opaque pointers -- and it's not strictly
> necessary for the goal of multi-threading. I'm just trying to be
> pragmatic here.

What if we modeled constants as implicit arguments to functions rather than introducing a constant materialization instruction?  That would solve the problem of making their use lists function local, while avoiding some of the unnecessary complexity introduced by materialization functions (de-duplication, code placement, etc.).

--Owen