similar to: [LICM][MemorySSA] Converting LICM pass to use MemorySSA to avoid AliasSet collapse issue

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

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

I suspect something is pulling the RHS of the memorydef and caching it for calls it should not be used for. In particular, i suspect we are about to discover we can't cache the results from both versions of getClobberingMemoryAccess together, or that the cache is not always getting consistently written. On Mon, May 2, 2016 at 11:16 AM, George Burgess IV < george.burgess.iv at

I've put my changes to EarlyCSE that trigger this case up on phab here: http://reviews.llvm.org/D19821. These changes depend on http://reviews.llvm.org/D19664 so that will need to be applied first. With these changes applied, the original attached .ll file should trigger this bug when compiled with opt -early-cse -early-cse-use-memoryssa On 5/2/2016 2:34 PM, Daniel Berlin wrote: >

In particular, if you want to add support, the right way to know what to rename is (off the top of my head) add a flag or something to have renamepass reset all uses it sees (you only have to change the uses, defs are all linked together and thus already fixed by the updater). Right now it only does that if they have no defining access. Make it skip blocks already in the visited set (the

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

When we erase a memory access instruction, existing passes using memory ssa like GVN, NewGVN, GVNHoist and EarlyCSE uses MemorySSAUpdater to do the update before the instruction is erased. However, if we call llvm::RecursivelyDeleteTriviallyDeadInstructions to find out dead instruction recursively and memory access instructions may be erased inside the recursive process, we need a way to update

> On Aug 18, 2020, at 16:59, Michael Kruse <llvmdev at meinersbur.de> wrote: > > Thanks for all the work. The reductions in stores look promising. Do you also have performance numbers how much this improves the execution time? Did you observe any regressions where MSSA resulted in fewer removed stores? I did not gather numbers for execution time yet, but I’ll try to share some

Hi Florian, First, thank you for working on this. I'm really glad to see this work so close to being enabled. I think the numbers look good for run time, and the benefits of switching for all configurations are clear. For compile time, the current regressions are noticeable, but not a deal breaker in my opinion. I'm very much in favor of switching in all configurations. To address some

Hi, Over the past six months, a MemorySSA-backed DSE implementation has been added to LLVM and it now covers almost all cases the existing DSE implementation does, plus adding a major new capability: eliminating stores across basic blocks. Thanks everyone involved with reviews, testing & patches! I think now would be a good time to start working towards switching to use MemorySSA-backed DSE

I understand that changing the starting element to “InsertedPHIs.being() + StartingPHISize” it will be finite but given that InsrtedPHIs is finite. I have a case where one element(same element is appened to InsertedPHIs) is added to InsertedPHIs every time fixupDefs is invoked. I traced the issue why this was happening. template <class RangeType> MemoryAccess

On Sun, Oct 30, 2016 at 4:08 PM, Bryant Wong < 3.14472+reviews.llvm.org at gmail.com> wrote: > > On Sun, Oct 30, 2016 at 6:48 PM, Daniel Berlin <dberlin at dberlin.org> > wrote: > >> In particular: >> " >> I'm not so sure that it's sufficient. Suppose, for instance, that I >> wanted to insert a MemoryDef between 1 and 2 in the below

On Sun, Oct 30, 2016 at 5:03 PM, Bryant Wong < 3.14472+reviews.llvm.org at gmail.com> wrote: > To give this a bit of context, this patch stems from issues that I've > encountered while porting MemCpyOpt to MSSA. > Okay. I'm not sure i would try to port instead of just rewrite. The whole goal of MemorySSA is to enable us to write memory optimizations in non-N^2 ways. If

On Sat, Sep 23, 2017 at 9:55 AM, Godala, Bhargav-reddy < Bhargav-reddy.Godala at amd.com> wrote: > > With regards > Bhargav Reddy Godala > Software Engineer 2 > Bangalore, India > E-mail: Bhargav-reddy.Godala at amd.com Ext 30678 > > > > On 23-Sep-2017, at 9:27 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > > On Sat, Sep 23, 2017 at

With regards Bhargav Reddy Godala Software Engineer 2 Bangalore, India E-mail: Bhargav-reddy.Godala at amd.com<mailto:Bhargav-reddy.Godala at amd.com> Ext 30678 On 23-Sep-2017, at 9:27 PM, Daniel Berlin <dberlin at dberlin.org<mailto:dberlin at dberlin.org>> wrote: On Sat, Sep 23, 2017 at 8:38 AM, Godala, Bhargav-reddy via llvm-dev <llvm-dev at

We should only add phis that were newly inserted, not ones that were already found. There are two cases we will hvae inserted phis: Part of the recursive call, or right in this function. The easiest way to differentiate new phis from old ones is whether they have 0 operands. I expect the attached will fix it. If not, please file a bug with reproducible IR. On Sun, Sep 24, 2017 at 11:40 PM,

Hi Florian, Following up on D86967, I missed that all the timings were using the legacy pass manager. Did you do any testing on the compile and run time impact for the new pass manager? Thank you, Alina On Tue, Aug 25, 2020 at 12:51 PM Florian Hahn <florian_hahn at apple.com> wrote: > Hi, > > Thanks for all the responses! > > My understanding is that there were no

Hi, I have a question about how llvm MemorySSA works, as seems I misunderstand something. Consider following code snippet and corresponding IR with MemorySSA annotations (got with opt -print-memoryssa) void foo(int* b) { int a = 0; int d = 12; if (b) { a = 42; d = 32; } int c = a; int e = d; } ; Function Attrs: noinline nounwind optnone uwtable

Hi, I wanted to give a heads-up that I've been looking into replacing the AliasSetTracker(AST) with MemorySSA in the Loop Invariant Code Motion (LICM) pass. I would love to get feedback on the best way to incrementally push in this change. Motivation: There has been an outstanding issue with using the Alias Set Tracker due to its expensive construction time (quadratic). We've had test