[llvm-dev] Multi-Threading Compilers

[Nicolai Hähnle via llvm-dev]

On Thu, Mar 26, 2020 at 11:19 AM Nicolai Hähnle <nhaehnle at gmail.com> wrote:
> 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.

I feel like I should clarify this after thinking a bit more about this.

It sounds like "constant materialization instructions" are a useful
feature to have for better location information (for diagnostics and
debug info). And _introducing_ constant materialization instructions
should be quite feasible to do incrementally. For example, if Clang or
some other frontend sees a use case for adding those in order to do
more work in IR rather than on the AST, then that should be
supportable.

The thing that I think is "extremely invasive in terms of churn in the
code base" is making constant materialization instructions the _only_
representation of constants inside a function. Which means that this
path is not very viable if your goal is to enable multi-threaded
compilation.

However, if your goal is to move towards constant materialization
instructions for the other benefits that they can bring, then there is
an incremental path available that can quickly bring you gains -
something along the lines of:

1. The initial MVP: Introduce constant materialization instructions as
a concept. Add a switch to the Builder so that constants are
optionally emitted as materialization instructions, start using that
switch in at least one frontend, add/convert some initial passes to
make use of them, and add a very simple pass that strips them out
again for the remainder of the compilation pipeline.

2. Teach an increasing number of passes, analyses, matching
infrastructure, etc. about the constant materialization instructions.

3. Eventually, get to the point where the pass that strips them out
can be removed. Somewhere around that time, we can make the Builder
unconditionally emit them everywhere.

4. Flip the switch that starts aborting when old-style Constants are
used instead.

5. Cleanup any remains of old constant support e.g. in the matching
infrastructure.

This seems viable, but very much a marathon and not a sprint, and I
feel that this is going away a bit from the topic of multi-threading
:)

Cheers,
Nicolai
-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.