search for: misundrstand

On Feb 29, 2020, at 2:08 PM, David Blaikie <dblaikie at gmail.com> wrote: > I've > curious as > to how MLIR deals with IPO as that's the problem I was running into. > > FWIW I believe LLVM's new pass manager (NPM) was designed with parallelism and the ability to support this situation (that MLIR doesn't? Or doesn't to the degree/way in which the NPM

.../WritingAnLLVMPass.html> doc if >> curious). >> > > I think the specific thing that might'v been a bit different in the NPM > was to do with analysis invalidation in a way that's more parallelism > friendly than the previous one - but I may be > misrepresenting/misundrstanding some of it. > > >> The problem is that LLVM has global use-def chains on constants, >> functions and globals, etc, so it is impractical to do this. Every >> “inst->setOperand” would have to be able to take locks or use something >> like software transactional me...

...doc if >>> curious). >>> >> >> I think the specific thing that might'v been a bit different in the NPM >> was to do with analysis invalidation in a way that's more parallelism >> friendly than the previous one - but I may be >> misrepresenting/misundrstanding some of it. >> >> >>> The problem is that LLVM has global use-def chains on constants, >>> functions and globals, etc, so it is impractical to do this. Every >>> “inst->setOperand” would have to be able to take locks or use something >>> like s...

...ous). >>>> >>> >>> I think the specific thing that might'v been a bit different in the NPM >>> was to do with analysis invalidation in a way that's more parallelism >>> friendly than the previous one - but I may be >>> misrepresenting/misundrstanding some of it. >>> >>> >>>> The problem is that LLVM has global use-def chains on constants, >>>> functions and globals, etc, so it is impractical to do this. Every >>>> “inst->setOperand” would have to be able to take locks or use something...