search for: memssa

Hello, while invoking opt with all possible optimization pairs I stumbled over a stack dump when doing -early-cse-memssa twice: $ clang -Xclang -disable-O0-optnone -S -o fannkuch7.ll -emit-llvm fannkuch7.c $ opt -S -o fannkuch7.ll -early-cse-memssa -early-cse-memssa fannkuch7.ll Questions: Is it illegal to call -early-cse-memssa twice? Are there any other incompatible optimization orders? Best, HwJ --- $ c...

...will find GEP 0, 0. > > If I understand it correctly getelementptr with zeros is just bitcast. Is > > there any good reason why it is not canonicalized into bitcast? > > > > Hi, > is there any particular reason why you're trying to fix this in MemDep > (and not in MemSSA?) > > GVN uses MemDep and MemSSA doesn't handle invariant.group. I was told that MemDep won't go out soon and it is easier for me right now to fix my stuff there than in MemSSA. I have plans to write support for MemSSA, but probably not in near future. > -- > Davide > >...

...I understand it correctly getelementptr with zeros is just bitcast. >> Is >> > there any good reason why it is not canonicalized into bitcast? >> > >> >> Hi, >> is there any particular reason why you're trying to fix this in MemDep >> (and not in MemSSA?) >> >> GVN uses MemDep and MemSSA doesn't handle invariant.group. I was told > that MemDep won't go out soon and it is easier for me right now to fix my > stuff there than in MemSSA. I have plans to write support for MemSSA, but > probably not in near future. > &gt...

...t program can be found here: https://gist.github.com/kavon/92d153cdd54ce9b77162af3af47d4c95 Here's what happens: kavon at cronus:~/m/autotune|master⚡*? ➤ /Users/kavon/msr/llvm5/bin/opt -inline -mem2reg -inferattrs -ipconstprop -gvn -simplifycfg -bdce -sink -dse -adce -instcombine -early-cse-memssa -early-cse-memssa -dse -adce -simplifycfg -sink -ipconstprop -gvn -bdce -instcombine -jump-threading -inline -sroa ./src/apps/raytracer.bc -o ./out/raytracer_opt1043.bc 0 opt 0x000000010ebd4498 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40 1 opt...

...#39;t handle invariant.group if it will find GEP 0, 0. > If I understand it correctly getelementptr with zeros is just bitcast. Is > there any good reason why it is not canonicalized into bitcast? > Hi, is there any particular reason why you're trying to fix this in MemDep (and not in MemSSA?) -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare

...I understand it correctly getelementptr with zeros is just bitcast. >> Is >> > there any good reason why it is not canonicalized into bitcast? >> > >> >> Hi, >> is there any particular reason why you're trying to fix this in MemDep >> (and not in MemSSA?) >> >> GVN uses MemDep and MemSSA doesn't handle invariant.group. I was told > that MemDep won't go out soon and it is easier for me right now to fix my > stuff there than in MemSSA. I have plans to write support for MemSSA, but > probably not in near future. > &gt...

Hi Zide, I think I found the right way to reach my goal. I used the following command: clang -O3 -Xclang -disable-llvm-optzns main.c -S -emit-llvm -o main.ll to generate an IR file enriched by all the metadata that otherwise wouldn't be generated with -O0. Moreover, -disable-llvm-optzns flag ensures that none of the optimization passes has been applied yet to the IR. In this way, I can

...SSA by default. This change has been in tree for a while and I've done benchmark and self-hosting testing on both aarch64 and x86, but I wanted to give other folks with different tests/targets a chance to try this out before I flip the switch. I've added an option '-enable-earlycse-memssa' (or '-enable-npm-gvn-hoist' if you're using the new pass manager) that you can be used to test this change out. Thanks, -- Geoff Berry Employee of Qualcomm Datacenter Technologies, Inc. Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qua...

...That's good. Anyway I already have a patch that is doing invariant group > dependence across BBs, so I guess it make sense to push it upstream to push > the bar higher. > But I think we are getting a little bit of topic - should gep 0 be > canonicalized to bitcast? > Are memdep/memssa the only possible passes that could benefit from such a canonicalization or you can think of other cases when this can be useful?

...n in tree for a while and I've > > done benchmark and self-hosting testing on both aarch64 and x86, but I > > wanted to give other folks with different tests/targets a chance to try > this > > out before I flip the switch. I've added an option > '-enable-earlycse-memssa' > > (or '-enable-npm-gvn-hoist' if you're using the new pass manager) that > you > > can be used to test this change out. > > > > Not that I don't trust your self-hosting test strategy, but other > passes (e.g. GVNHoist or NewGVN) showed us that...

...a patch that is doing invariant group > > dependence across BBs, so I guess it make sense to push it upstream to > push > > the bar higher. > > But I think we are getting a little bit of topic - should gep 0 be > > canonicalized to bitcast? > > > > Are memdep/memssa the only possible passes that could benefit from > such a canonicalization or you can think of other cases when this can > be useful? > We already canonicalize. We canonicalize in the other direction: https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/InstCombine/InstCombineC...

...group >> > dependence across BBs, so I guess it make sense to push it upstream to >> push >> > the bar higher. >> > But I think we are getting a little bit of topic - should gep 0 be >> > canonicalized to bitcast? >> > >> >> Are memdep/memssa the only possible passes that could benefit from >> such a canonicalization or you can think of other cases when this can >> be useful? >> > > We already canonicalize. We canonicalize in the other direction: > https://github.com/llvm-mirror/llvm/blob/master/ > lib/Tra...

...nce across BBs, so I guess it make sense to push it upstream to >>> push >>> > the bar higher. >>> > But I think we are getting a little bit of topic - should gep 0 be >>> > canonicalized to bitcast? >>> > >>> >>> Are memdep/memssa the only possible passes that could benefit from >>> such a canonicalization or you can think of other cases when this can >>> be useful? >>> >> >> We already canonicalize. We canonicalize in the other direction: >> https://github.com/llvm-mirror/llvm/b...

...a patch that is doing invariant group > > dependence across BBs, so I guess it make sense to push it upstream to > push > > the bar higher. > > But I think we are getting a little bit of topic - should gep 0 be > > canonicalized to bitcast? > > > > Are memdep/memssa the only possible passes that could benefit from > such a canonicalization or you can think of other cases when this can > be useful? > > > We already canonicalize. We canonicalize in the other direction: > https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/InstCombin...

...tion that replaces all uses of a basic block with another basic > block in one operation, and yet you want to have a way to perform some > analysis as if the transformation happened one change at a time. This was, > at least originally, used for the incremental domtree updater and for > memssa. (+cc Alina, as she is most familiar with GraphDiff) > This is used because the CFG used in LLVM changes all the time, right? If so, I don't see this being useful for us, since we don't mess with Clang's CFG much once it's built. > I'd separate out a base of IDFCalculat...

...lately (I found it up to 50% faster in compile time on some internal benchmarks). There are some places were we can improve. For example, we spend a lot of time inside Simplify* functions. Another considerable chunk of the time is spent inside MemorySSA, but this is going to change once we preserve MemSSA more aggressively. * The code is easier to understand (at least to me) [...] Some current limitations of NewGVN: * NewGVN doesn't do everything that the current GVN does. There are plans to implement missing features and more. * On small testcases NewGVN may be slower as it does some work upfr...

Hi Daniel, Thanks for the info. I’ve started looking into converting EarlyCSE to use MemorySSA first since 1) I don’t think it needs any additional MemorySSA update API and 2) the particular case I’m looking at needs EarlyCSE to catch more load cases before LICM to be profitable. I have a prototype working, but have run into two issues: 1) readonly calls are treated as clobbers by

Hi everyone, I started digging into MemDep to enhance devirtualization and I found out that it doesn't handle invariant.group if it will find GEP 0, 0. If I understand it correctly getelementptr with zeros is just bitcast. Is there any good reason why it is not canonicalized into bitcast? Example: define void @_Z5testGv() local_unnamed_addr #0 { entry: * %a* = alloca %struct.A, align 8

A polite ping, could someone please share a thought about this? On Sat, 8 Jun 2019 at 21:21, Kristóf Umann <dkszelethus at gmail.com> wrote: > A polite ping on this matter :) > > On Tue, 4 Jun 2019 at 01:51, Kristóf Umann <dkszelethus at gmail.com> wrote: > >> Hi! >> >> As the title suggests, I'd like to generalize llvm::IDFCalculator to be >>

...group >> > dependence across BBs, so I guess it make sense to push it upstream to >> push >> > the bar higher. >> > But I think we are getting a little bit of topic - should gep 0 be >> > canonicalized to bitcast? >> > >> >> Are memdep/memssa the only possible passes that could benefit from >> such a canonicalization or you can think of other cases when this can >> be useful? >> >> >> We already canonicalize. We canonicalize in the other direction: >> https://github.com/llvm-mirror/llvm/blob/master/...