[llvm-dev] Multi-Threading Compilers

Florian Hahn via llvm-dev llvm-dev at lists.llvm.org
Thu Mar 26 03:53:24 PDT 2020



> On Mar 26, 2020, at 10:19, Nicolai Hähnle via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 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.
> 

Agreed, it is not production solution. I think it was not really clear from my previous mail, but I see it mostly as a relatively cheap approach (in terms of work required to get it working) to try to get to a state where we can run experiments with function passes in parallel and get a better idea of the benefit and turn up other issues.


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



I am not sure why not. Function passes should only rely on the information at the callsite & from the declaration IIRC. For functions, we coulkd add extra declarations and update the call sites. But I might be missing something.

Cheers,
Florian


More information about the llvm-dev mailing list