search for: loopidiomrecognizer

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

Hi, I'm having problems with the LoopIdiomRegognizer crashing on me with An asserting value handle still pointed to this value! UNREACHABLE executed at ../lib/IR/Value.cpp:695! If I remove AU.addPreserved<LoopInfoWrapperPass>(); or AU.addPreserved<AAResultsWrapperPass>(); everything goes well. The C-code triggering this is void foo(int a[10][10]) { int i, j,

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 !=

Hi Haicheng, Originally I ran into this on our out-of-tree target but I managed to reproduce the crash on X86 as well now: build-all/bin/opt -S -sroa -loop-rotate -loop-deletion -licm -loop-idiom ../llvm/bugpoint-reduced-simplified.i8+.ll gives: While deleting: void % An asserting value handle still pointed to this value! UNREACHABLE executed at ../lib/IR/Value.cpp:696! 0 opt

Hi, SelectionDAGBuilder 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

I’m digging through a build failure [1], and it looks like the loop idiom recognizer adds some instructions [2], and then removes them again [3]. I don’t understand why yet, but the LegacyPassManager detects that the structural hash of the function has changed, and complains that the pass didn’t correctly report that it changed the function [4] (even though materially, it didn’t). This raises a

I've been looking at 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

Hi, On 02/10/2016 01:23 AM, haicheng at codeaurora.org wrote: > Thank you, Mikael. I can reproduce what you saw and am looking into it. Great! > Just curious, why do you run loop-deletion before licm and loop-idiom? As part of our internal testing we use Csmith to generate C-programs and then we run the compiler with random generated compiler flags on that input. This bug was

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 give...

Hi, I was looking at Rust programs which are poorly optimized by LLVM, and one occasional factor is that LLVM allows for long-lived `br i1 false` instructions. The problem is that if a propagation pass discovers the condition of a branch, the branch itself will not be eliminated until a SimpllfyCfg pass is reached, of which there are few in the pipeline. One example is

Thanks a lot for your help. Indeed if I compile with -OZ the loop gets replaced with something like this: if ( *v3 < 0 ) v4 = 0; Is there a reason why it does not get applied with O3 ? I mean this a huge improvement to the loop. -----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

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; }

Hi David, sorry for sending you the mail two times, I forgot to send to the list the first time. On 2014-03-12 09:48, David Chisnall wrote: > I have some patches that automatically expand all memcpy and similar > if the operands are not in AS 0. I think this is probably not quite > the right approach though, and we should be asking the back end for > the function that does a memcpy

I probably wouldn't worry about 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

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++; .. ..

On Thu, Apr 19, 2018 at 2:53 PM Tim Northover <t.p.northover at gmail.com> wrote: > On 19 April 2018 at 22:36, Manoj Gupta via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I was looking around for the cases where AddrSpace !=0 are checked. Seems > > like there are a bunch of optimizations that will fail to apply for non > zero > > address spaces. >

On Thu, Apr 19, 2018 at 3:56 PM, Manoj Gupta via llvm-dev <llvm-dev at lists.llvm.org> wrote: > My understanding is we only want to disable the optimizations regarding > undefined behavior > related to null pointer deference optimizations. And address space checks > will end up > disabling more optimizations than needed. [Repeating what others have already mentioned on this

>> 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() {