search for: memdepanalysi

...was PhiValuesAnalysis not > being properly updated, and BasicAA having an instance of it. > PhiValuesAnalysis now uses callback values to invalidate deleted > values (r340613 > <https://reviews.llvm.org/rL340613>),PhiValuesAnalysis is also > being updated in MemDepAnalysis (D48489 > <https://reviews.llvm.org/D48489>) and BasicAA is invalidated if > PhiValuesAnalysis gets invalidated. > > I may not have the full context here, so I'd like some feedback: > does it make sense to make BasicAA a CFG-only pass again? > > T...

.... >From what I gathered the motivation was PhiValuesAnalysis not being properly updated, and BasicAA having an instance of it. PhiValuesAnalysis now uses callback values to invalidate deleted values ( r340613 <https://reviews.llvm.org/rL340613>), PhiValuesAnalysis is also being updated in MemDepAnalysis (D48489 <https://reviews.llvm.org/D48489>) and BasicAA is invalidated if PhiValuesAnalysis gets invalidated. I may not have the full context here, so I'd like some feedback: does it make sense to make BasicAA a CFG-only pass again? Thank you, Alina -------------- next part ------------...

...is time (we won't have benefits as large at the time of the switch). I'm talking about getting the geomean closer to 1% in all configurations if possible. I believe that the regressions introduced by this flag flip can be undone by further using MemorySSA in the other passes currently using MemDepAnalysis, and offsetting the cost of computing MemorySSA in the first place. The threshold could be raised again to enable more stores eliminated once the MemCpyOpt+MSSA and NewGVN become the default. If reducing the thresholds is not possible or removes most of the run time benefits, I would vote for ena...

...efits > as large at the time of the switch). I'm talking about getting the geomean > closer to 1% in all configurations if possible. > > I believe that the regressions introduced by this flag flip can be > undone by further using MemorySSA in the other passes currently using > MemDepAnalysis, and offsetting the cost of computing MemorySSA in the first > place. The threshold could be raised again to enable more stores eliminated > once the MemCpyOpt+MSSA and NewGVN become the default. > > > > If reducing the thresholds is not possible or removes most of the run > t...

...nce not be done syntactically in Clang?  -Hal > > So I'm trying to follow a pointer from a point of origin > (i.e. addrspacecast private ptr -> generic ptr) and look through a > sequence of bitcasts, GEPs, function calls and pointer copies through > memory. AliasAnalysis and MemDepAnalysis give me all the required > information to do intraprocedural analysis, except for the memcpy case > that I raised in this thread. > > Since a failure to infer an address space means a compilation error, I'm > trying to get this analysis working for debug builds, where we do not...

On 12/5/18 9:51 AM, Andrew Savonichev via llvm-dev wrote: >> Hi, >> >> I'm trying to get AA results for two pointers, but it seems that AA >> cannot look though a memcpy. For example: >> >> define dso_local spir_func void @fun() { >> entry: >> ; Store an address of `var' >> %var = alloca i32, align 4 >>

Programmers’ manual says we can iterate over a use-def chain by op_iterator. It works fine except for load and store instruction of stack variables. For example, a simple bitcode is like the below. i = alloca i32 store i32 0, i32* %i, align 4 %tmp1 = load i32* %i, align 4 If I apply a use-def chain to load instruction, I get alloca instruction. I think store instruction is a correct

> 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

...users for MemorySSA means more testing. MemorySSA-backed DSE makes extensive use of MemorySSA which increases the test-coverage MemorySSA gets. It already surfaced one issue, that has since been fixed. More users also likely means more eyes on tuning MemorySSA. 3. Eliminating some long-standing MemDepAnalysis related issue. MemoryDependenceAnalysis used by the current DSE implementation makes heavy use of caching and is relatively fragile with respect to cache invalidation. I think there are at least a few long-standing known issues in that area, e.g. https://bugs.llvm.org/show_bug.cgi?id=28014 4. L...

...e step this issue. Neither is entirely simple to implement, but both are doable. Probably. In theory, we've now solved the same problem my loop nest transform does. There's two snags: one minor(ish), one major. The minor one is that many of my rare conditions involve volatile loads. MemDepAnalysis currently completely gives up when faced with volatile loads. This is mostly fixable, but given the structure of the code may be fairly invasive. Oddly, LICM actually performs better in this case. For the major one, let's tweak our example slightly: while(c) { x = this->x; if (x...

I've been playing with approaches to getting better optimization of loops which contain infrequently executed slow paths. I've gotten as far as throwing together a proof of concept implementation of a profile guided optimization to separate a single loop with multiple latches into a loop nest, but I want to get feedback from interested parties before investing much more effort. The