similar to: [LLVMdev] opt, loopidiom pass and compiling system libraries

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

It seems some optimization pass converts some address computation add's into or's when it knows it's allowed due correct alignment. How do I turn this off keep the address calculations as adds?

On Fri, Dec 09, 2011 at 10:03:37AM +0100, Seb wrote: > I think my explanation is not clear, my front-end did NOTt generate > 'llvm.memcpy' it generate LL code that after use of LLVM 'opt' get > transformed by 'loop-idom' pass into an 'llvm.memcpy' for an overlapping > loop: > > static void > t0(int n) > { > int i; > for (i=0;

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

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

2011/12/9 Joerg Sonnenberger <joerg at britannica.bec.de> > On Fri, Dec 09, 2011 at 10:03:37AM +0100, Seb wrote: > > I think my explanation is not clear, my front-end did NOTt generate > > 'llvm.memcpy' it generate LL code that after use of LLVM 'opt' get > > transformed by 'loop-idom' pass into an 'llvm.memcpy' for an overlapping >

The code itself makes sense, but I want to know if this breaks any guarantee made about preserving a Value* in the MachineMemOperand. It sounds like we're having the same issue. We were using the Value* stored in the MachineMemOperand to get address space information during assembly printing. The alternative is carrying around a lot of extra (redundant) information in the SDAG. If it is

On Thu, Sep 29, 2011 at 3:06 AM, Heikki Kultala <hkultala at iki.fi> wrote: > > > make[1]: Entering directory > `/home/hkultala26/src/llvm-trunk/llvm/tools/llvm-config' > llvm[1]: Regenerating LibDeps.txt.tmp > llvm[1]: Checking for cyclic dependencies between LLVM libraries. > find-cycles.pl: Circular dependency between *.a files: > find-cycles.pl:

make[1]: Entering directory `/home/hkultala26/src/llvm-trunk/llvm/tools/llvm-config' llvm[1]: Regenerating LibDeps.txt.tmp llvm[1]: Checking for cyclic dependencies between LLVM libraries. find-cycles.pl: Circular dependency between *.a files: find-cycles.pl: libLLVMPTXAsmPrinter.a libLLVMPTXCodeGen.a libLLVMPTXDesc.a llvm[1]: Building llvm-config script. cat:

Hello Devang, answers are interleaved 2011/12/7 Devang Patel <dpatel at apple.com> > Hello, > > On Dec 7, 2011, at 2:07 AM, Seb wrote: > > > Hi all, > > > > I would like to add an option for LLVM 'opt' to disable a specific > optimization pass from command line. > > > > The idea is to have something like: > > > > opt -O2

Hi, In feedback from game studios a common issue is the replacement of loops with calls to memcpy/memset. These loops are often hand-optimised, and highly-efficient and the developers strongly want a way to control the compiler (i.e. leave my loop alone). The culprit is of course the loop-idiom recognizer. This replaces any loop that looks like a memset/memcpy with calls. This affects loops

My concern wasn't a phylosophical one but a pragmatic one. Learning about poor choices when lowering memset is probably quite useful. Having a flag that just turns off idiom recognition for it may just work around the problem. But the problem may still exist. In any case, I'm not fundamentally against such a flag but it just seems like something that could 1. Hide a problem 2. Get a bit

David, I think my explanation is not clear, my front-end did NOTt generate 'llvm.memcpy' it generate LL code that after use of LLVM 'opt' get transformed by 'loop-idom' pass into an 'llvm.memcpy' for an overlapping loop: static void t0(int n) { int i; for (i=0; i<n; i++) result[i+1] = result[i]; } Then 'llc' expanded llvm.memcpy into a

> For instance, I figured out that loop-idiom pass has a BUG in > LLVM 2.9, a llvm.memcpy is generated for an overlapping memory region and > then x86 backend reorder loads/store thus generating a BUG. Just for the record it seems this is a bug in your frontend, not in the LLVM backend. The memcpy intrinsic, like the standard memcpy function, requires that the regions be non-overlapping:

LLVM code base seems to be full of base/interface classes, which have methods like virtual SDValue LowerCall(SDValue Chain, SDValue Callee, CallingConv::ID CallConv, bool isVarArg, bool &isTailCall, const SmallVectorImpl<ISD::OutputArg> &Outs, const SmallVectorImpl<SDValue> &OutVals, const

On 29 Jan 2013, at 10:20, Tobias Grosser wrote: > On 01/28/2013 07:45 PM, Tanya Lattner wrote: >> I will be removing the list prefix "LLVMDev" from the subject line. If you are filtering by this, please use the list headers instead. >> >> If you have any questions, please let me know. > > Thanks Tanya, this makes the subject lines of the commits a lot more

On 25 Aug 2010, at 02:04, Silvio Ricardo Cordeiro wrote: > On Sun, Aug 15, 2010 at 10:04 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Aug 15, 2010, at 5:12 PM, Silvio Ricardo Cordeiro wrote: > > > Is there a way for me to collect statistics about the number of loads/stores added by the "linearscan" register allocator (just like can be done with

On 1 Oct 2010, at 13:35, Bill Wendling wrote: > On Sep 30, 2010, at 2:13 AM, Heikki Kultala wrote: > >> Bill Wendling wrote: >>> On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote: >>> >>>> On 29 Sep 2010, at 06:25, Heikki Kultala wrote: >>>> >>>>> Our architecture has 1-bit boolean predicate registers. >>>>>

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,

On Tue, Aug 15, 2017 at 9:37 PM, Tim Northover via cfe-dev < cfe-dev at lists.llvm.org> wrote: > On 15 August 2017 at 19:38, bharathi seshadri via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I find that GCC has an option -fno-tree-loop-distribute-patterns that > > can be used to disable memcpy/memset synthesis. I wonder if there is > > something similar