search for: predicateinfo

Hi, Nikita pointed me to an issue in the full restrict patches, related to name mangling used for llvm-ir functions (See [0, 3]). The problem is the following: Given: %0 = type { i32 } %1 = type { i32 } Creating an intrinsic @llvm.FOO that accepts 'a pointer to %0' cannot be distinguished from the intrinsic accepting 'a pointer to %1': ;For a %0* ptr0, %1* ptr1

On 7/7/2017 4:59 PM, Davide Italiano wrote: > On Fri, Jul 7, 2017 at 1:47 PM, Chad Rosier <mcrosier at codeaurora.org> wrote: >> David/Johan, >> >> I would love to claim victory, but I don't think that D34901 catches this >> case. >> > Hi Chad, thanks for taking another look at this. > Maybe I didn't bisect correctly. Apologies. Anyway, more fun

..., > pop the relevant ones when you exit the relevant dom tree scope. > > In practice, you'd only check comparisons against the hash table. Humm.. I'll have to think about it for a bit. I'm thinking this might be a good compromise for my needs. > > The other option is PredicateInfo, but it requires dominators and > modifies the IR. > > My guess is this is undesired/too heavyweight for inline cost > analysis, however the basic principle on how it renames things could > also be applied without IR changing for this specific case. Unlike > the EarlyCSE meth...

2017-10-14 5:03 GMT+02:00 Daniel Berlin <dberlin at dberlin.org>: > FWIW: We hit a subset of this issue with MemorySSA (which subclasses value > for the MemoryAccess's, etc), and it was discussed as well during > PredicateInfo. > > NewGVN has a variant the same issue as well, where it actually creates > unattached (IE not in a basic block) new instructions just so it can analyze > them. > > IMHO, some nice way to make virtual forms over the instructions that didn't > require reimplementing the to...

...2 1 } becomes define i32 @test1(i32 %x) { %cmp = icmp eq i32 %x, 50 br i1 %cmp, label %true, label %false true: ; preds = %0 ; Has predicate info ; branch predicate info { TrueEdge: 1 Comparison: %cmp = icmp eq i32 %x, 50 } %x.0 = call i32 @llvm.predicateinfo.i32(i32 %x) ret i32 %x.0 false: ; preds = %0 ret i32 1 } All uses that are dominated by the predicate info are renamed to use it. 2. We do so very quickly (it takes about 600ms to do 2 million blocks with comparisons, by comparison, most passes simp...

...the equivalences you see, pop the relevant ones when you exit the relevant dom tree scope. In practice, you'd only check comparisons against the hash table. Humm.. I'll have to think about it for a bit. I'm thinking this might be a good compromise for my needs. The other option is PredicateInfo, but it requires dominators and modifies the IR. My guess is this is undesired/too heavyweight for inline cost analysis, however the basic principle on how it renames things could also be applied without IR changing for this specific case. Unlike the EarlyCSE method, which is O(all instructons) P...

All, I'm working on an improvement to the inline cost model, but I'm unsure how to proceed. Let me begin by first describing the problem I'm trying to solve. Consider the following pseudo C code: *typedef struct element { unsigned idx; } element_t; * *static inline unsigned char fn2 (element_t *dst_ptr, const element_t *a_ptr, const element_t *b_ptr,

...a pass in the pipeline where the dominator tree was > available (note my patch used a poor man's version of domination) and to > add range meta-data to values (or replace values if we know the exact > value) based on dominating conditions. This is a pretty trivial variant of what the predicateinfo utility does :) (it just happens to process branches, assumes, etc. But you could trivially modify it to change the name anywhere the range is different, to ensure the invariant that anything with the same ssa name has the same range) I thought it was pretty interesting idea, but I'm not ver...

...GMT+02:00 Daniel Berlin <dberlin at dberlin.org > <mailto:dberlin at dberlin.org>>: > > FWIW: We hit a subset of this issue with MemorySSA (which > subclasses value > > for the MemoryAccess's, etc), and it was discussed as well during > > PredicateInfo. > > > > NewGVN has a variant the same issue as well, where it actually > creates > > unattached (IE not in a basic block) new instructions just so it > can analyze > > them. > > > > IMHO, some nice way to make virtual forms...

...gt; In practice, you'd only check comparisons against the hash > table. > > > Humm.. I'll have to think about it for a bit. I'm thinking > this might be a good compromise for my needs. > > > The other option is PredicateInfo, but it requires > dominators and modifies the IR. > > My guess is this is undesired/too heavyweight for inline > cost analysis, however the basic principle on how it > renames things could also be applied without IR changing >...

Hi All, We have recently found some optimization opportunities created by replicating code into branches in order to enable optimization. In general, the optimization opportunity we are pursuing is like the following. Given pseudo-code: // block A if (some condition) // block B // block C If it can be efficiently proven that some portion of block C can be simplified had control flow not

>Do you recall the arguments why it was considered a bad idea? Felt like long time ago, but it turned out that was actually just a bit over a year ago. Here's the thread. http://lists.llvm.org/pipermail/llvm-dev/2016-August/104079.html Only a few explicitly responded, but I took that as silent majority was satisfied with the responses. Prior to that thread, I also pinged HPC oriented LLVM

...xample: define i32 @f1(i32 %x) { bb0: %cmp = icmp eq i32 %x, 0 br i1 %cmp, label %bb2, label %bb1 bb1: br label %bb2 bb2: %cond = phi i32 [ %x, %bb0 ], [ %x, %bb1 ] %foo = add i32 %cond, %x ret i32 %foo } the critical edge from bb0 to bb2 causes us to have no place to place predicateinfo in the current algorithm for the true branch (we will placefalse info). You could also always place it before each branch its for (because that block should dominate all uses in the conditional edges already) . The actual placement is irrelevant, BTW. In the renaming algorithm, by the time it goe...

...t; 2017-10-14 5:03 GMT+02:00 Daniel Berlin <dberlin at dberlin.org <mailto:dberlin at dberlin.org>>: >> > FWIW: We hit a subset of this issue with MemorySSA (which subclasses value >> > for the MemoryAccess's, etc), and it was discussed as well during >> > PredicateInfo. >> > >> > NewGVN has a variant the same issue as well, where it actually creates >> > unattached (IE not in a basic block) new instructions just so it can analyze >> > them. >> > >> > IMHO, some nice way to make virtual forms over the instructi...

Hi, It's been a while since I sent the last compile time report [1], where it was shown that LLVM was getting slower over time. But now I'm happy to bring some good news: finally, LLVM is getting faster, not slower :) *** Current status *** Many areas of LLVM have been examined and improved since then: InstCombine, SCEV, APInt implementation, and that resulted in almost 10% improvement