> 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
On Thu, Mar 26, 2020 at 11:53 AM Florian Hahn <florian_hahn at apple.com> wrote:> > 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.Function passes can remove, duplicate, or just plain introduce call sites (e.g. recognize a memset pattern), which means the use lists of Functions can be changed during a function pass... Cheers, Nicolai -- Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.
> On Mar 26, 2020, at 10:55, Nicolai Hähnle <nhaehnle at gmail.com> wrote: > > On Thu, Mar 26, 2020 at 11:53 AM Florian Hahn <florian_hahn at apple.com> wrote: >>> 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. > > Function passes can remove, duplicate, or just plain introduce call > sites (e.g. recognize a memset pattern), which means the use lists of > Functions can be changed during a function pass…Sure, but a single function won’t be processed in parallel by a function pass and would just work on the 'local version' of the globals it uses, including called functions. So a function pass adding/removing calls to existing ‘local versions’ of functions should not be a problem I think. One problem is that function passes can add new global, e.g. new declarations if they introduce new calls. I guess that would require some locking, but should happen quite infrequently. Cheers, Florian
Doerfert, Johannes via llvm-dev
2020-Mar-26 15:26 UTC
[llvm-dev] Multi-Threading Compilers
On 3/26/20 5:53 AM, Florian Hahn wrote:>> 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.FWIW, I think deleting and creating functions (or globals in general) should be hidden behind an API that would allow us to synchronize things in parallel runs. I don't believe there are many passes that would be affected and we could "easily" make this happen. Hide the constructors and destructors so that only the friend API can access it.> Cheers, > Florian
> On Mar 26, 2020, at 8:26 AM, Doerfert, Johannes <jdoerfert at anl.gov> wrote: > > On 3/26/20 5:53 AM, Florian Hahn wrote: >>> 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. > > FWIW, I think deleting and creating functions (or globals in general) > should be hidden behind an API that would allow us to synchronize things > in parallel runs. > > I don't believe there are many passes that would be affected and we > could "easily" make this happen. Hide the constructors and destructors > so that only the friend API can access it.Right, this is what MLIR does. However, keep in mind that this is just one piece of the puzzle. You also have things like ValueHandles which get owned by IPA passes. The CallGraph used by the inline persists across function pass manager runs, and needs to be correctly updatable in order to run CallGraphSCC passes. Getting to a multithread clean optimizer is not one bug fix away - this is a multiyear journey, and I would prefer not to see big changes with unclear tradeoffs made in an effort to get a quick win. Instead, let’s break down the problems and fix them (the right way!) one at a time. For example, it seems that the thread agrees that the overall design of constants are a problem: let's talk about (incrementally!) moving constants to the right architecture. There are good suggestions about this upthread. -Chris