search for: earlycse

There’s a few passes in LLVM that make heavy use of a big DenseMap, one that potentially gets filled with up to 1 entry for each instruction in the function. EarlyCSE is the best example, but Reassociate and MachineCSE have this to some degree as well (there might be others?). To put it simply: at least in my profile, EarlyCSE spends ~1/5 of its time growing DenseMaps. This is kind of… bad. grow() is inherently slow because it needs to rehash and reinsert every...

Hi All, I'd like to switch the function simplification run of EarlyCSE to use MemorySSA 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 '-e...

Hi George, After digging a little deeper, it appears that readonly calls showing up as MemoryDefs is only happening on an EarlyCSE test that is using the new pass manager (test/Transforms/EarlyCSE/basic.ll test5 if you’re curious), so I suspect it is an issue with the new pass manager setup code for either MemorySSA, my changes to EarlyCSE, the test run command line or something else not related to the MemorySSA code proper....

...10, 2017 at 2:45 PM, Davide Italiano via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Sat, Jun 10, 2017 at 8:21 AM, Geoff Berry via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Hi All, > > > > I'd like to switch the function simplification run of EarlyCSE to use > > MemorySSA 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...

1) Sounds good. This isn’t holding me up so I’ll just try to keep an eye out for these changes. 2) I’ve attached an example IR file and debug log of where the caching is going bad. It depends on my changes to EarlyCSE, but hopefully it is clear from the debug output what is going on. Let me know if there is a better way to get this repro case to you. Also, I’ll be on IRC for the next couple of hours if you would like to have a quicker discussion. -- Geoff Berry Employee of Qualcomm Innovation Center, Inc...

Hi Chris (or anyone else), Today I ran across a stack overflow in EarlyCSE::processNode(). Basically, the issue is that EarlyCSE::processNode() is recursive and with a very large function, such as the machine generated one I have, it blows the stack. The attached script generates a function which re-creates the problem. On my 64-bit FreeBSD 7.3 build machine I come ac...

...> On Tue, Mar 15, 2016 at 3:07 PM, via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > There’s a few passes in LLVM that make heavy use of a big DenseMap, one that potentially gets filled with up to 1 entry for each instruction in the function. EarlyCSE is the best example, but Reassociate and MachineCSE have this to some degree as well (there might be others?). To put it simply: at least in my profile, EarlyCSE spends ~1/5 of its time growing DenseMaps. This is kind of… bad. > > grow() is inherently slow because it needs to rehash and rein...

...:09 PM, Philip Reames <listmail at philipreames.com> wrote: > > > > On 03/15/2016 03:07 PM, via llvm-dev wrote: >> There’s a few passes in LLVM that make heavy use of a big DenseMap, one that potentially gets filled with up to 1 entry for each instruction in the function. EarlyCSE is the best example, but Reassociate and MachineCSE have this to some degree as well (there might be others?). To put it simply: at least in my profile, EarlyCSE spends ~1/5 of its time growing DenseMaps. This is kind of… bad. >> >> grow() is inherently slow because it needs to rehash...

...Apr 19, 2014 at 6:38 AM, Hal Finkel <hfinkel at anl.gov> wrote: > Jingyue, > > I can't speak for the NVPTX backend, but I think this looks useful as an > (optional) target-independent pass. A few thoughts: > > - Running GVN tends to be pretty expensive; have you tried EarlyCSE > instead? (When I was working on the BB vectorizer I was first using GVN for > cleanup afterward, someone suggested trying EarlyCSE instead, the > performance slowdown was a bit less than 1% on average, but the runtime > impact was much less). > EarlyCSE surprisingly generates code...

I'm working on enhancing EarlyCSE to use MemorySSA and have come across the following issue due to differences in EarlyCSE and MemorySSA's handling of !invariant.load. EarlyCSE will *not* currently optimize the following code by replacing %x2 with %x and removing the second load: B1: %x = load %p clobbe...

...and memory footprint measurements at least for CTMark? For a new pass/feature it would be great to share this with the community before you commit. Or did I miss them? Thanks Gerolf > On Jun 27, 2017, at 3:26 PM, Geoff Berry via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > EarlyCSE w/ MemorySSA has been enabled by default as of r306477 > > > On 6/19/2017 2:42 PM, Geoff Berry via llvm-dev wrote: >> Sounds good to me. >> >> >> On 6/19/2017 2:27 PM, Davide Italiano via llvm-dev wrote: >>> On Mon, Jun 19, 2017 at 11:22 AM, Nemanja Iva...

...timization easier. It can help transforms that duplicate code (like loop unrolling and inlining) be more profitable -- I'm thinking of cases where unrolling/inlining would have to duplicate a lot of code, but after outlining would require duplicating only a few call instructions. It can help EarlyCSE do things that require GVN today: void foo() { ... complex computation that computes func() ... complex computation that computes func() } outlining=> int func() { ... } void foo() { int x = func(); int y = func(); } functionattrs=> int func() readonly { ... } void foo(int a, i...

Hi guys, I think I have run into another CachingMemorySSAWalker cache bug. It's a bit tricky to reproduce, so I'd like to start by trying to show you what is happening when running EarlyCSE with my local changes to use MemorySSA. I've attached a debug log that shows that the value returned by getClobberingMemoryAccess(Inst) after a call to removeMemoryAccess is wrong. The MemorySSA node in question is MemoryUse(7), and the corruption happens after a call to remove MemoryUse(...

...t;> llvm-dev at lists.llvm.org> wrote: >> >>> On Sat, Jun 10, 2017 at 8:21 AM, Geoff Berry via llvm-dev >>> <llvm-dev at lists.llvm.org> wrote: >>> > Hi All, >>> > >>> > I'd like to switch the function simplification run of EarlyCSE to use >>> > MemorySSA 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 >>&...

Sounds good to me. On 6/19/2017 2:27 PM, Davide Italiano via llvm-dev wrote: > On Mon, Jun 19, 2017 at 11:22 AM, Nemanja Ivanovic via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> For what it's worth, I just ran this on PowerPC and a double bootstrap with >> lit and lnt tests passes everything. >> > I fixed the only bug that has been reported (there were

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 treate...

...ptimizations (I'm repeating a few examples that Hal mentioned earlier). 1. >A readnone function is one whose output is a function only of its inputs, and if you have this: > > int *x = malloc(4); > *x = 2; > int *y = malloc(4); > *y = 4; > you certainly don't want EarlyCSE to replace the second call to malloc with the result of the first (which it will happily do if you mark malloc as readnone). >>> It sounded like improving GlobalsAA (and thus disambiguation against globals) was the explicit goal, and that the concern with the malloc case was that you don&...

...M, Geoff Berry <gberry at codeaurora.org> > wrote: > >> Hi guys, >> >> I think I have run into another CachingMemorySSAWalker cache bug. It's a >> bit tricky to reproduce, so I'd like to start by trying to show you what is >> happening when running EarlyCSE with my local changes to use MemorySSA. >> I've attached a debug log that shows that the value returned by >> getClobberingMemoryAccess(Inst) after a call to removeMemoryAccess is >> wrong. The MemorySSA node in question is MemoryUse(7), and the corruption >> happens af...

...he two fields of the array struct as disjoint branches in the TBAA tree, I can inform LLVM that a load of 'len' never aliases with a store through 'data'. This mostly works, and enables many loads to be forwarded by GVN, but (due to the intervening stores) is a complete loss in EarlyCSE and (due to intervening calls) LICM. a) Things like http://llvm.org/bugs/show_bug.cgi?id=20805 could improve the situation in EarlyCSE. 2) Use "invariant.load" metadata - This metadata indicates that the field loaded from is initialized before the execution of the code being compi...

...discriminators (3) on function (7) matches_S running pass (1) Simplify the CFG on function (7) matches_S running analysis pass Dominator Tree Construction on function (7) matches_S running pass (2) SROA on function (7) matches_S running pass (3) Early CSE on function (7) matches_S Another case (1): EarlyCSE CSE value Another case (2): EarlyCSE CSE value Another case (3): EarlyCSE CSE value Another case (4): EarlyCSE CSE load Another case (5): EarlyCSE CSE value Another case (6): EarlyCSE CSE load Another case (7): EarlyCSE CSE value Another case (8): EarlyCSE CSE load NOT running pass (4) Lower 'e...