similar to: [LLVMdev] Stack overflow in EarlyCSE

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

For what it's worth, I just ran this on PowerPC and a double bootstrap with lit and lnt tests passes everything. On Sun, Jun 11, 2017 at 12:38 AM, Zhendong Su via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Sure, we are happy to start some testing to see what we may help find. > > On Sat, Jun 10, 2017 at 3:36 PM, Daniel Berlin <dberlin at dberlin.org> > wrote:

+1 If possible, it definitely helps to fuzz it. On Sat, Jun 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

Can you share you compile-time 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 >

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

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

What should we use instead of DenseMap? —escha > On Mar 15, 2016, at 3:30 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > > yes it makes sense. Avoid using DenseMap when the size of the map is expected to be large but can not be pre-determined. > > David > > On Tue, Mar 15, 2016 at 3:07 PM, via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at

> On Mar 15, 2016, at 4: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

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 clobber() ... B2: // dominated by B1 %x2 = load %p

Hi Hal, Thanks for your comments! I'm inlining my responses below. Jingyue On Sat, 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

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.

----- Original Message ----- > From: "Hal Finkel via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Geoff Berry" <gberry at codeaurora.org> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, August 25, 2016 3:05:48 PM > Subject: Re: [llvm-dev] invariant.load metadata semantics > ----- Original Message ----- > >

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

> On Mar 25, 2016, at 12:10 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Mar 25, 2016, at 11:56 AM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi Andy, >> >>> On Mar 25, 2016, at 11:41 AM, Kaylor, Andrew via llvm-dev <llvm-dev at

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

Hi, On Wed, Jul 26, 2017 at 10:10 AM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > No, I mean in terms of enabling other optimizations in the pipeline like > vectorizer. Outliner does not expose any of that. I have not made a lot of effort to understand the full discussion here (so what I say below may be off-base), but I think there are some cases where

Maybe someone on the list who knows about GHC internals (I don't) can chime in here, but GHC has (had?) a concept of "optimization fuel": http://blog.ezyang.com/2011/06/debugging-compilers-with-optimization-fuel/ that is very similar to what Mehdi is suggesting. -- Sanjoy On Fri, Mar 25, 2016 at 12:37 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >

Andy, I'd love to see this feature. I wouldn't care too much wether the interface is a single number or two numbers, but if possible print the name of the function and the name of the pass that was just skipped so the developers knows where to start looking. - Matthias > On Mar 25, 2016, at 12:13 PM, Kaylor, Andrew via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi

<<< I may misunderstand, but it seems to me that this solves only query for aliasing with a pointer known to be pointing only to globals defined in the current compilation unit. For any pointer which "may point somewhere else”, you won’t be able to resolve the non-aliasing with the “internal state” for malloc/free, right? To take the original example in this thread: int *x =