similar to: Question regarding LICM

On Mar 19, 2008, at 2:03 PM, Török Edwin wrote: > > What is kext64, and how do I disable it? Comes from: APPLE_LOCAL='APPLE LOCAL libcc_kext' \ MULTILIBS="`$(GCC_FOR_TARGET) --print-multi-lib` static;@static at fno-pic kext;@Dmal loc=kern_os_malloc at Dfree=kern_os_free at DLIBCC_KEXT@static at fno-pic@fno- exceptions at fno-non-ca

Bill Wendling wrote: > On Wed, Mar 19, 2008 at 12:11 PM, Duncan Sands <baldrick at free.fr> wrote: > >> Hi Bill, thanks for fixing it. >> >> > No prob! :-) I can't build llvm-gcc4.2 on x86-32 Linux. What is kext64, and how do I disable it? (I suppose I don't need it on a 32-bit platform?) ..... ranlib kext/libgcc_eh.a

On targets that fully support MC for encoding (today that means X86, hopefully ARM will be done soon), llc has a "-show-mc-encoding" option that can be used to dump out the encodings for every instruction. If you're using clang, this can be accessed with the (intentionally) hidden -mllvm option like so: $ clang t.c -S -o - -mllvm -show-mc-encoding -mkernel -O3 -fomit-frame-pointer

On Wed, Mar 19, 2008 at 12:11 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Bill, thanks for fixing it. > No prob! :-) > > > > ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c: In function 'ix86_expand_convert_uns_DI2DF_sse': > > > ../../gcc-4.2.llvm.master/gcc/config/i386/i386.c:10270: warning: large integer implicitly truncated to unsigned type

Thanks, Mike! I applied this to the tree. Török, please give it a try. In the meantime, I'm going to try on a Linux machine I just got access to. -bw On Wed, Mar 19, 2008 at 2:37 PM, Mike Stump <mrs at apple.com> wrote: > On Mar 19, 2008, at 2:03 PM, Török Edwin wrote: > > > > What is kext64, and how do I disable it? > > Comes from: > >

I am using LLVM 2.6 and I have a question on the use of the BasicBlock::iterator to hoist loop invariant instructions to the loop preheader. When I process the instructions backward as shown in the following code, I got the following error right after the "hoist(I)" is done. Can anyone advise whether I am misusing BasicBlock::iterator? /opt/llvms/src/llvm_26/

Hi Gang-Ryung! Your reverse iteration of instructions in the BB > * for (BasicBlock::iterator II = BB->end(); II != BB->begin(); ) *{ > > Instruction &I = *--II; > > if (isLoopInvariantInst(I) && canSinkOrHoistInst(I) && > isSafeToExecuteUnconditionally(I)) > * hoist(I);* >

Hi, I recently looked into the LICM(Loop Invariant Code Motion) pass of LLVM and got a question about hoist load instruction to loop preheader. I would like to show two examples: Example 1: int func(int n, int *fp) { int i; int a[1000]; for (i = 0; i < n; ++i) { a[i] += *fp; // load from *fp pointer, no hoist } } Here, load *fp CAN NOT be hoisted to loop preheader. If replace *fp

Specifying -no-implicit-float prevents LLVM from using non-GPR registers for purely integer operations. This is useful for operating systems (such as Wind River's VxWorks) that support tasks that do not save all registers on context switch. This presents an interesting problem for variadic functions that may optionally take non-integer arguments (e.g. printf style functions). Should non-GPR

On Dec 14, 2010, at 9:37 PM, Chris Lattner wrote: > On targets that fully support MC for encoding (today that means X86, hopefully ARM will be done soon), llc has a "-show-mc-encoding" option that can be used to dump out the encodings for every instruction. If you're using clang, this can be accessed with the (intentionally) hidden -mllvm option like so: > > $ clang t.c

I'm running into a compile problem with commit 131656 of compiler-rt. I'm compiling llvm with: $ CXX='g++ -m32' CC='gcc -m32' CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32 ./configure --disable-bindings --{build,host,target}=i686-apple-darwin --enable-targets=x86,x86_64,cbe --enable-optimized $ make $ make install It will eventually error out with:

Thanks for reviving this topic! Interestingly we have essentially the same fix you mention below ( https://reviews.llvm.org/D62639) as a local change in our Wind River version of LLVM. The reason we didn't try to push it upstream (and in fact have considered removing it) is due to an unfortunate side-effect which is either "expected" or a "bug" depending on your

Hi, We have a research LLVM-based domain-specific code generator that we want to upgrade form LLVM 4.0 to 5.0. The code generator is written as an out-of-tree loadable module for opt. Till Clang 4.0 we were compiling the front-end code (annotated C++) using -O0. The generated bitcode was further processed using opt with our module loaded. In Clang 5.0 we see that using -O0 adds the optnone

2012/2/3 Patrik Hägglund <patrik.h.hagglund at ericsson.com>: > Hi, > > I've tracked the first problem (mentioned in my previous email, quoted > below) down further, ending up in the handling of alloca in > LoopRotation.cpp (from trunk): > >      // If the instruction's operands are invariant and it doesn't read > or write >      // memory, then it is

Does any real code benefit from dead code eliminating read-only functions? Tom ----- Original Message ----- From: "Reid Kleckner" <rnk at mit.edu> To: "Thomas B. Jablin" <tjablin at CS.Princeton.EDU> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Monday, May 10, 2010 9:38:47 PM GMT -05:00 US/Canada Eastern Subject: Re: [LLVMdev]

Hi, We are upgrading an LLVM 4.0-based opt module to LLVM 5.0. After the upgrade our module works when built with an LLVM Debug build, but with an LLVM Release build we are encountering the following error. This happens after our passes have successfully run. I believe this has to do with the way our passes are registered. Would greatly appreciate some pointers, as to where to look. Program

Hi, All CallInsts should return true for Instruction::mayHaveSideEffects() because functions are not guaranteed to halt. Inliner::runOnSCC calls isInstructionTriviallyDead to determine whether code can be dead code eliminated. isInstructionTriviallyDead returns true if Instruction::mayHaveSideEffects() returns false. A function that potentially runs forever based on its input but does not write

Hi, I've tracked the first problem (mentioned in my previous email, quoted below) down further, ending up in the handling of alloca in LoopRotation.cpp (from trunk): // If the instruction's operands are invariant and it doesn't read or write // memory, then it is safe to hoist. Doing this doesn't change the order of // execution in the preheader, but does

Hi All, I'm looking into converting LICM to use MemorySSA instead of AliasSets to determine when it is safe to hoist/sink/promote loads and stores to get around the issue of alias set collapse (see discussion [1]). I have a prototype implementation, but have run into two issues that I could use input from the designers of MemorySSA to resolve: 1) Is MemorySSA intended to be

Hi Daniel, Thanks for the info. I’ve started looking into converting EarlyCSE to use MemorySSA first since 1) I don’t think it needs any additional MemorySSA update API and 2) the particular case I’m looking at needs EarlyCSE to catch more load cases before LICM to be profitable. I have a prototype working, but have run into two issues: 1) readonly calls are treated as clobbers by