search for: cachingmemoryssawalker

...l.com> wrote: > Yeah, that sounds like a fun bug. I'll take a look later today and see > what I can find out. :) > > On Fri, Apr 29, 2016 at 2:55 PM, 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 >> getClobberingMemoryA...

...1) readonly calls are treated as clobbers by MemorySSA which leads to extra walking of MemoryDefs to not regress some EarlyCSE test cases. This isn’t a huge deal, I’m just wondering if it is intentional or something that just hasn’t been gotten to yet. 2) There seems to be a bug in the CachingMemorySSAWalker invalidation causing it to return MemoryAccess nodes that have been removed. In the case I’m seeing, a call node is removed from MemorySSA which causes CachingMemorySSAWalker::invalidateInfo() to clear the CachedUpwardsClobberingCall map. However, this same call node is present as a value in the...

...k later today > and see what I can find out. :) > > On Fri, Apr 29, 2016 at 2:55 PM, Geoff Berry > <gberry at codeaurora.org <mailto: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...

...This isn’t a huge deal, I’m just wondering if it is intentional or something that just hasn’t been gotten to yet. George is working on the optimizations, of which this is one. I think this is one of the ones his current patch (under review) addresses. 2) There seems to be a bug in the CachingMemorySSAWalker invalidation causing it to return MemoryAccess nodes that have been removed. In the case I’m seeing, a call node is removed from MemorySSA which causes CachingMemorySSAWalker::invalidateInfo() to clear the CachedUpwardsClobberingCall map. However, this same call node is present as a value in the...

Hi All, I'm looking into converting LICM to use MemorySSA instead of AliasSets to determine when it is safe to hoist/sink/promote loads and stores to get around the issue of alias set collapse (see discussion [1]). I have a prototype implementation, but have run into two issues that I could use input from the designers of MemorySSA to resolve: 1) Is MemorySSA intended to be

...This isn’t a huge deal, I’m just wondering if it is intentional or something that just hasn’t been gotten to yet. George is working on the optimizations, of which this is one. I think this is one of the ones his current patch (under review) addresses. 2) There seems to be a bug in the CachingMemorySSAWalker invalidation causing it to return MemoryAccess nodes that have been removed. In the case I’m seeing, a call node is removed from MemorySSA which causes CachingMemorySSAWalker::invalidateInfo() to clear the CachedUpwardsClobberingCall map. However, this same call node is present as a value in 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 rem...