search for: loopidiomrecogn

On 27.10.2012, at 18:24, Benjamin Kramer <benny.kra at gmail.com> wrote: > > On 27.10.2012, at 18:15, Sean Silva <silvas at purdue.edu> wrote: > >> How does this affect freestanding implementations? > > This transform is disabled with -fno-builtin or -ffreestanding. Thinking a bit more about this, it looks like the way -ffreestanding is implemented in clang is

...Pass>(); everything goes well. The C-code triggering this is void foo(int a[10][10]) { int i, j, k; for (i = 0; i < 1; i++) { for (j = 0; j < 2; j++) { for (k = 0; k < 10; k++) { a[j][k] = 42; } } } } First LoopIdiomRecognize replaces the store in the inner loop with a memset in the outer loop, and later, when examining the outer loop it tries to replace that memset with an even bigger memset in the outermost loop. But then, when removing the "old" memset, the assert blows. I don't know LoopIdiomRec...

Hello. Could you please tell me why am I not able to recognize (with LLVM built from the SVN code in Apr 25, 2018) the LLVM IR intrinsic ctpop (described at https://llvm.org/docs/LangRef.html#llvm-ctpop-intrinsic) in the following program: int PopCnt_Simple(int x) { int numBits = 0; int i; //for (i = 0; i < 32; i++) { for (i = 0; x !=

...foo(int a[10][10]) > { > int i, j, k; > > for (i = 0; i < 1; i++) { > for (j = 0; j < 2; j++) { > for (k = 0; k < 10; k++) { > a[j][k] = 42; > } > } > } > } > > First LoopIdiomRecognize replaces the store in the inner loop with a memset in the outer loop, and later, when examining the outer loop it tries to replace that memset with an even bigger memset in the outermost loop. But then, when removing the "old" memset, the assert blows. > > I don't know LoopId...

...lder doesn't know how to lower a Memcpy and Memset if one of the pointer operands have an address space >= 256. This is understandable since the libc's memcpy / memset don't work for these address spaces. However, both Clang (when copying a struct) and some optimization passes (LoopIdiomRecognize, MemCpyOpt) can emit memcpy / memset for these address spaces. This triggers an assert in SelectionDAGBuilder. The optimization passes could be modified to give up when they encounter an address space >= 256, but I think clang would need some new code that emits a struct copy member-by-...

...-RA-expensive/16803/consoleFull#-1371525106d489585b-5106-414a-ac11-3ff90657619c <http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-expensive/16803/consoleFull#-1371525106d489585b-5106-414a-ac11-3ff90657619c> 2: https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Scalar/LoopIdiomRecognize.cpp#L931 <https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Scalar/LoopIdiomRecognize.cpp#L931> 3: https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Scalar/LoopIdiomRecognize.cpp#L936 <https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transf...

...t compilation time issues in the LICM pass, and it looks to me like colorEHFunclets() is probably being called a lot more often than it needs to be for functions that have Windows EH personality functions. For one thing, the funclet coloring is happening when computeLoopSafetyInfo() is called from LoopIdiomRecognize and LoopUnswitch but those passes don't use the coloring information. Beyond that, it's called for every loop within LICM even though in many case the information won't have changed since being computed for other loops in the same function. I was thinking about pulling the funclet...

...i < 1; i++) { >>> for (j = 0; j < 2; j++) { >>> for (k = 0; k < 10; k++) { >>> a[j][k] = 42; >>> } >>> } >>> } >>> } >>> >>> First LoopIdiomRecognize replaces the store in the inner loop with a >>> memset in the outer loop, and later, when examining the outer loop it >>> tries to replace that memset with an even bigger memset in the outermost >>> loop. But then, when removing the "old" memset, the assert b...

It seems LoopIdiomRecognizer pass recognizes one loop inside memSet as memset and replaces it with memset intrinsic, which might then be converted into memset call, resulting in infinite recursion. There is parameter -fno-builtins to prevent this, BUT when executing opt as "standalone", this parameter cannot be...

...oop unrolling, but the `br i1 false` instruction leaks to codegen. Another example is https://github.com/rust-lang/rust/issues/45466. In that case, induction variable simplification discovers that an integer overflow check is unnecessary, but the remaining `br i1 false` still blocks the following LoopIdiomRecognize pass and prevents the loop from being optimized to a memset. While it is possible to have point-fixes for both problems, this might be widespread enough problem that a more general solution might be better - for example, to have some sort of canonicalization that automatically removes these bra...

...-Original Message----- From: Doerfert, Johannes [mailto:jdoerfert at anl.gov] Sent: Dienstag, 13. August 2019 19:13 To: llvm-dev at lists.llvm.org; Garba Peter <peter.garba at gemalto.com> Subject: Re: Loop optimization Without testing it I'd say loop idiom recognition (Transforms/Scalar/LoopIdiomRecognize.h) is the one that should kick in and optimize this. ________________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Garba Peter via llvm-dev <llvm-dev at lists.llvm.org> Sent: Tuesday, August 13, 2019 11:54 To: llvm-dev at lists.llvm.org Su...

Hey Preston, I wanted to let you know that we found a really serious problem with DependenceAnalysis in PR14241. In summary, DA seems to have a baked-in assumption that the base pointer of the GEPs it inspects are loop invariant. It appears to only do analysis on the subscripts. This is especially important for LLVM because C++ code (compiled through Clang) very frequently expresses loops as

Hi, I was wondering if there is an optimization pass in LLVM or Polly that can optimize this given loop: int main(int argc, char* argv[]) { char s = 0; // Loop is setting s = argv[1][0]; for (int i=0; i<argv[1][0]; i++) { s++; } printf("s = %c\n", s); return 0; }

...Memcpy and Memset if >> one of the pointer operands have an address space >= 256. This is >> understandable since the libc's memcpy / memset don't work for these >> address spaces. However, both Clang (when copying a struct) and some >> optimization passes (LoopIdiomRecognize, MemCpyOpt) can emit memcpy / >> memset for these address spaces. This triggers an assert in >> SelectionDAGBuilder. The optimization passes could be modified to >> give up when they encounter an address space >= 256, but I think clang >> would need some new code...

...the cost of LoopInfo; it's relatively cheap to compute.  But if you're really concerned, you can run your pass after a pass which preserves LoopInfo (so it's free because it was already computed).  Or you can stick your code into an existing pass which requires LoopInfo anyway, like LoopIdiomRecognize. -Eli On 4/23/2018 3:37 PM, Anom LLVM wrote: > Thanks for the answer Eli. > > I think I was a little too vague in my question. The program has the > following structure: > void foo() { >   bar(); > } > > void bar() { >   for (..) { >        __builtin_compute()...

Hi, Look at the following code: Look at the following C code seqence: unsigned char mainGtU ( unsigned int i1, unsigned int i2, unsigned char* block) { unsigned char c1, c2; c1 = block[i1]; c2 = block[i2]; if (c1 != c2) return (c1 > c2); i1++; i2++; c1 = block[i1]; c2 = block[i2]; if (c1 != c2) return (c1 > c2); i1++; i2++; .. ..

...behavior related to null pointer deference optimizations. And address space checks will end up disabling more optimizations than needed. I did look at some of the optimizations/transforms and there are some that we definitely want to keep. Just a quick example from grepping: lib/Transforms/Scalar/LoopIdiomRecognize.cpp ........... // Don't create memset_pattern16s with address spaces. StorePtr->getType()->getPointerAddressSpace() == 0 && (PatternValue = getMemSetPatternValue(StoredVal, DL))) { // It looks like we can use PatternValue! return...

...ions that exploit UB" and instead frame this as "define some behavior that was undefined before". > I did look at some of the optimizations/transforms and there are some that > we definitely want to keep. > > Just a quick example from grepping: > lib/Transforms/Scalar/LoopIdiomRecognize.cpp > ........... > // Don't create memset_pattern16s with address spaces. > StorePtr->getType()->getPointerAddressSpace() == 0 && > (PatternValue = getMemSetPatternValue(StoredVal, DL))) { > // It looks like we can use...

>> Agreed. If ld64 can drop support for .o produced by the old gcc that >> would be awesome. Failing that, what is really needed is > Because of static archives, the linker has to support old .o files for quite a while. I also don’t know when clang starting getting this right. r123585 (Jan 16 17:19:34 2011) I think. > Also, this seems like linker complexity for a very

Thanks for the answer Eli. I think I was a little too vague in my question. The program has the following structure: void foo() { bar(); } void bar() { for (..) { __builtin_compute() } } We would like to use scalar evolution + loopinfowrapperpass inside instcombine only if __builtin_compute is present. instcombine can convert the loop into a single builtin ie. void bar() {