"Multithreaded LLVM" in "Writing an LLVM Pass"

Hello all,

I have read the chapter “Writing an LLVM Pass” and noticed that there is a
topic “Multithreaded LLVM”. However I have no idea about this. I am wondering
to know whether the goal of this extension is:

  1. Multiple threads handle different modules (Thread : Module = 1 : 1)
    or
  2. Multiple threads handle one module (Thread : Module = N : 1)

Thanks a lot

Should be this.

Regards,
chenwj

1. Multiple threads handle different modules (Thread : Module = 1 : 1)
or

For ModulePasses, yes.

2. Multiple threads handle one module (Thread : Module = N : 1)

For FunctionPasses, yes.

Note that this part is in the future work section, meaning that no one has done it yet. FunctionPasses are independent of each other when running on different functions, so it would be fairly simple to use something like libdispatch to optimise every function within a module independently. FunctionPasses are not (in theory) allowed to modify any module state outside of a function, so they should be able to be run concurrently.

David

> 1. Multiple threads handle different modules (Thread : Module = 1 : 1)
> or

For ModulePasses, yes.

> 2. Multiple threads handle one module (Thread : Module = N : 1)

For FunctionPasses, yes.

Note that this part is in the future work section, meaning that no one has
done it yet. FunctionPasses are independent of each other when running on
different functions, so it would be fairly simple to use something like
libdispatch to optimise every function within a module independently.
FunctionPasses are not (in theory) allowed to modify any module state
outside of a function, so they should be able to be run concurrently.

To the best of my knowledge this is not true: global variables' use-def
chains are shared (as are Constants, but for less good reason there).

I have a completely crazy plan for how to parallelize function passes, but
it is not at all clear that it will work, and even if it does, it is a very
significant and invasive change to LLVM's core infrastructure.

No one has done it yet? From [1], it seems parallel JIT is workable.
Or I just misread the question?

Regards,
chenwj

[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-January/046901.html

Your citation refers to a proprietary program that was presented at EuroLLVM - their changes are not upstream. They are running multiple MCJIT instances in parallel, but they are completely independent - different modules and different LLVMContexts, and so passes are completely independent (unless they do something silly like have some mutable static variables). This is a completely unrelated problem.

David

MachinePasses don't change llvm::Module nor llvm::Function. I think
CodeGen could be prallelized.

In contrast, as Chandler mentions, Modifying Instruction(s) might
affect *hidden* state of globals, use-ref chain and refcount.

I think "transaction" might be useful here, too. See also
http://llvm.org/bugs/show_bug.cgi?id=2116

Hi David,

  No one has done it yet? From [1], it seems parallel JIT is workable.
Or I just misread the question?

Your citation refers to a proprietary program that was presented at EuroLLVM - their changes are not upstream. They are running multiple MCJIT instances in parallel, but they are completely independent - different modules and different LLVMContexts, and so passes are completely independent (unless they do something silly like have some mutable static variables). This is a completely unrelated problem.

As one of the authors of that paper, I'd just like to add a few points here. We didn't make any changes to the LLVM code base, so the idea can be implemented with the standard LLVM infrastructure. But you're right, we are exploiting parallelism on a higher level than Lu suggested: we are indeed using completely separate JIT instances (of the old JIT, in fact) so the problem of dependences between passes doesn't occur.

Tobias