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

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

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