similar to: RFC Storing BB order in llvm::Instruction for faster local dominance

Hi folks, I looked into some slow compiles and filed https://bugs.llvm.org/show_bug.cgi?id=38829. The gist of it is that we spend a lot of time iterating basic blocks to compute local dominance, i.e. given two instructions in the same BB, which comes first. LLVM already has a tool, OrderedBasicBlock, which attempts to address this problem by building a lazy mapping from Instruction* to position.

On 09/21/2018 01:30 PM, Chris Lattner via llvm-dev wrote: On Sep 19, 2018, at 1:30 PM, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi folks, I looked into some slow compiles and filed https://bugs.llvm.org/show_bug.cgi?id=38829. The gist of it is that we spend a lot of time iterating basic blocks to compute local dominance, i.e.

Did you consider using the waymarking algorithm we already use for going from Use->User to store the offset of an instruction in a basic block? We could steal the two bits needed from the bb parent pointer in the instruction. -- Sanjoy On Mon, Sep 24, 2018 at 10:20 AM Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > To echo what Hal said, yes, it's a major

On Tue, Sep 25, 2018 at 12:16 PM Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Let's not assume a dichotomy between storing a int64 in > llvm::Instruction and bitwise tricks -- they're both ways of caching > position within llvm::Instruction. I think we first need to establish > that we need such a cache in llvm::Instruction/llvm::BasicBlock at > all. >

On Tue, Sep 25, 2018 at 10:45 PM Chris Lattner <clattner at nondot.org> wrote: > So this is one of the reasons I find your patch to be problematic: it > isn’t fixing N^2 behavior, it is merely changing one N^2 situation for > another. AFAICT there are one of two possible cases in these sorts of > transformations: > > 1) These transformations are iteratively removing or

> On Sep 24, 2018, at 10:19 AM, Reid Kleckner <rnk at google.com> wrote: > > To echo what Hal said, yes, it's a major change, but I think the improved complexity guarantees, simplicity, and elimination of certain classes of bugs is worth it. > > I think we have consensus that we should go forward with this. Would anyone mind formally stamping it in phab? So far everyone

On Mon, Sep 24, 2018 at 10:07 PM Chris Lattner <clattner at nondot.org> wrote: > > On Sep 24, 2018, at 9:54 PM, Chris Lattner <clattner at nondot.org> wrote: > >> I think we have consensus that we should go forward with this. Would > anyone mind formally stamping it in phab? So far everyone understandably > has said "makes sense to me, but I don't

On 09/27/2018 12:24 AM, Chris Lattner via llvm-dev wrote: On Sep 26, 2018, at 11:55 AM, Reid Kleckner <rnk at google.com<mailto:rnk at google.com>> wrote: As suggested in the bug, if we were to rewrite these passes to use MemorySSA, this bottleneck would go away. I rebased a patch to do that for DSE, but finishing it off and enabling it by default is probably out of scope for me.

Thanks for the reply! It sounds like LLVM IR is being considered for optimizations in OpenMP constructs. There seems to be plans regarding improvement of LLVM IR Framework for providing things required for OpenMP / flang(?) Are there any design considerations which contain pros and cons about using the MLIR vs LLVM IR for various OpenMP related optimizations/ transformations? The latest RFC [

Hi, I have few questions / concerns regarding the design of OpenMP dialect in MLIR that is currently being implemented, mainly for the f18 compiler. Below, I summarize the current state of various efforts in clang / f18 / MLIR / LLVM regarding this. Feel free to add to the list in case I have missed something. 1. [May 2019] An OpenMPIRBuilder in LLVM was proposed for flang and clang frontends.

Hello everyone, Since MLIR landed today. I'm trying to build it using cmake ../llvm/ -DCMAKE_BUILD_TYPE=RELEASE -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ALL_PROJECTS="clang;lld;lldb;mlir" -DBUILD_SHARED_LIBS=ON -DCLANG_DEFAULT_LINKER:STRING=lld and also by adding -DLLVM_ALL_PROJECTS. It's giving this compilation error -- Building CXX object

These errors seem pretty pervasive for me on a clean build. It appears that it arises because when tablegen'd headers are included in a .h file, every place where that .h file is used needs a dependency on the corresponding IncGen targets. This seems broken in the short term and unmaintainable in the long term. There really needs to be a way of automatically generating the right

Hi all, The TensorFlow team at Google has been leading the charge to build a new set of compiler infrastructure, known as the MLIR project <https://github.com/tensorflow/mlir>. The initial focus has been on machine learning infrastructure, high performance accelerators, heterogeneous compute, and HPC-style computations. That said, the implementation and design of this infrastructure is

Please find the reply inline below On Sun, Feb 16, 2020 at 12:59 AM Mehdi AMINI <joker.eph at gmail.com> wrote: > > > On Sat, Feb 15, 2020 at 10:42 AM Vinay Madhusudan via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Reply to Kiran Chandramohan: >> >> > You are welcome to participate, provide feedback and criticism to >> change the

James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> writes: > The alternative I had in mind would be to rewrite the commits on the branch > so that all the files are under an mlir/ subdirectory, and then do a normal > merge from that. I just sent a message about import-downstream-repo.py, shown here: https://github.com/jyknight/llvm-git-migration/pull/6/commits The default

Am So., 12. Jan. 2020 um 20:07 Uhr schrieb Chris Lattner < clattner at nondot.org>: > The central idea is to use a modifiable loop tree -- similar to > LoopInfo -- as the primary representation. LLVM-IR is converted to a > loop tree, then optimized and finally LLVM-IR is generated again for > subtrees that are considered profitable. This is not a new concept, it > has already

Am Mo., 27. Jan. 2020 um 22:06 Uhr schrieb Uday Kumar Reddy Bondhugula < uday at polymagelabs.com>: > Hi Michael, > > Although the approach to use a higher order in-memory abstraction like the > loop tree will make it easier than what you have today, if you used MLIR > for this representation, you already get a round trippable textual format > that is *very close* to your

On Tue, Sep 10, 2019 at 1:40 PM David Greene via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > But perhaps more importantly, as Hal states clearly, is the need for > > an official specification, similar to the one for LLVM IR, as well as > > a formal document with the expected semantics into

+1 for batching. In practice it's probably more important that things get run for every MLIR checkin, and not necessarily for every LLVM checkin. Steve On Fri, Jul 31, 2020 at 9:26 AM Mehdi AMINI via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Indeed there is quite a backlog here right now: > http://lab.llvm.org:8011/builders/mlir-windows and here >

On Fri, Nov 15, 2019 at 10:58 AM Fāng-ruì Sòng <maskray at google.com> wrote: > Since you are going to rewrite the mlir history anyway, you can > probably delete accidentally checked in large files if any. > Good point, I checked and this is the largest file in the history of the repo as far as I can tell: