search for: findavailableloadedvalue

...d i32, i32* %b, align 4 %lv = load volatile i32, i32* %b %a1 = load i32, i32* %a, align 4 %result = add i32 %a0, %a1 ret i32 %result } to "%result = %a0 << 1" via -O3. NB: changing the volatile load to a volatile store triggers the optimization (via -instcombine) -- llvm::FindAvailableLoadedValue just skips over noalias ordered stores. -- Sanjoy

...32* %a, align 4 >> >> %result = add i32 %a0, %a1 >> ret i32 %result >> } >> >> to "%result = %a0 << 1" via -O3. >> >> NB: changing the volatile load to a volatile store triggers the >> optimization (via -instcombine) -- llvm::FindAvailableLoadedValue just >> skips over noalias ordered stores. >> >> -- Sanjoy >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >...

...t; I don't feel like it complicates our model that much, though. Passes already have to know that uninitialized allocas contain undef, and with this change they can contain a value. That doesn't seem very surprising. It is a fair point that we'd have to add new cases to code like llvm::FindAvailableLoadedValue, which looks for StoreInst but not AllocaInst. > A couple of other thoughts I had: > 1. We could use metadata, e.g. "%px = alloca i32, align 4 !argument !i32 > %x", followed by a store. There's still a little pattern-matching involved > because the metadata is only a hi...

...s available below, but I think it might be much harder to comprehend the data without the graph. A number in the end shows compile time change after the given commit: 1. r239821: [InstSimplify] Allow folding of fdiv X, X with just NaNs ignored. +1% 2. r241886: [InstCombine] Employ AliasAnalysis in FindAvailableLoadedValue. +1% 3. r245118: [SCEV] Apply NSW and NUW flags via poison value analysis for sub, mul and shl. +2% 4. r246694: [RemoveDuplicatePHINodes] Start over after removing a PHI. -1% 5. r247269: [ADT] Rewrite the StringRef::find implementation to be simpler... +1% r247240: [LPM] Use a map from analysis...

...hink it might be much harder to comprehend the data without the graph. A number in the end shows compile time change after the given commit: >> >> 1. r239821: [InstSimplify] Allow folding of fdiv X, X with just NaNs ignored. +1% >> 2. r241886: [InstCombine] Employ AliasAnalysis in FindAvailableLoadedValue. +1% >> 3. r245118: [SCEV] Apply NSW and NUW flags via poison value analysis for sub, mul and shl. +2% >> 4. r246694: [RemoveDuplicatePHINodes] Start over after removing a PHI. -1% >> 5. r247269: [ADT] Rewrite the StringRef::find implementation to be simpler... +1% >> r24...

...arder > to comprehend the data without the graph. A number in the end shows compile > time change after the given commit: > > > > 1. r239821: [InstSimplify] Allow folding of fdiv X, X with just NaNs > ignored. +1% > > 2. r241886: [InstCombine] Employ AliasAnalysis in > FindAvailableLoadedValue. +1% > > 3. r245118: [SCEV] Apply NSW and NUW flags via poison value analysis for > sub, mul and shl. +2% > > 4. r246694: [RemoveDuplicatePHINodes] Start over after removing a PHI. > -1% > > 5. r247269: [ADT] Rewrite the StringRef::find implementation to be > simpler... +...

On Thu, Dec 8, 2016 at 5:37 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > So IIUC basically the *only* reason for this IR change is that we don’t > want to pattern match in debug build? > I don't understand right now why we wouldn’t want to do this? > If we need to pattern match such a basic construct, it suggests to me that we have the wrong representation, and we

I’m taking a first look at InstCombine performance. I picked up the caching patch and ran a few experiments on one of our larger C++ apps. The size of the *.0.2.internalize.bc no-debug IR is ~ 30M. Here are my observations so far. Interestingly, caching produced a slight but measurable performance degradation of -O3 compile time. InstCombine takes about 35% of total execution time, of which ~20%

...> > Passes > > > already have to know that uninitialized allocas contain undef, and > > > with this change they can contain a value. That doesn't seem very > > > surprising. It is a fair point that we'd have to add new cases to > > > code like llvm::FindAvailableLoadedValue, which looks for StoreInst > > > but not AllocaInst. > > > > It's more that that... I mean, obviously you have to fix all the > > places which assume allocas start off containing undef, but you're > > also introducing the potential for missed optimizations b...