[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