[llvm-dev] Multi-Threading Compilers

[Nicolai Hähnle via llvm-dev]

On Wed, Mar 25, 2020 at 5:26 PM Florian Hahn <florian_hahn at apple.com> wrote:
> I think one important observation is that most passes currently probably do not really care too much about use lists of various constants, beyond the bookkeeping required to maintain them.

Agreed, though as Chris points out it's something that can and should
be tested experimentally fairly easily.


> We might be able to break the dependencies on GlobalValue without too much work directly as an IR transformation. I’ve not thought this completely through, but we might get away with a module pass that duplicate globals per function and replace all uses in a function with the copy per function before running a set of function passes. Then merge the duplicates again before running passes that inspect global uses.

That feels like a really awkward hack :(

Now you have to keep track of whether the IR is currently in the state
where function pass parallelization is okay or not, which seems rather
fragile.

It also doesn't solve the problem of Functions themselves -- those are
also GlobalValues...


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.


[snip]
> On Mar 25, 2020, at 4:14 PM, Doerfert, Johannes <jdoerfert at anl.gov> wrote:
> >
> >> Today, you can walk the use-list of any operand to an instruction.
> >> This would be broken by this change,
> >
> > First, you would be able to walk the use-list of any operand. So nothing
> > breaks just yet.
>
> If I understand correctly, you are suggesting that you can walk it, but you don’t get all the uses.  This is extremely dangerous, it would be better to abort.

Agreed.


> >> which would make it much easier to write buggy/incorrect compiler code
> >> and passes.
> >
> > I argued (implicitly) above that the uses of a Constant[Int/Float/...]
> > are really not interesting if no-one ever walks them.
>
> There is a difference between “no one ever walks them in practice” and “no one can walk them.    :-)

Yes, but you've got to ask yourself: what's the point of walking the
use list of a scalar constant? It feels like code that would do that
is quite likely broken to begin with and should probably abort already
today... which is exactly the experiment that you suggest below, and I
agree that doing this experiment would be a useful step in all this :)

Cheers,
Nicolai

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