similar to: [LLVMdev] clang branching using label

Hi Chris, > Clang normally generates code that looks like > > .... > ;<label>:22 ; preds = %0 > %23 = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([24 x i8]* > @.str, i32 0, i32 0)) > br label %24 > > ;<label>:24 ; preds = %22, %0 > %25 = load i32* %tmphigh,

How does the verifier deal with this? I'm noticing that if I load a clang compiled function (with -emit-llvm) and run the verifier, there is no problem. If I start mucking with the function body (adding an instruction), the verifier is unhappy saying the instructions that would have been in the commented out block aren't part of a basic block. Does the clang compiled function have some

Hi Duncan, A DragonEgg/GCC-related question: do you know where these strange FRAME tokens originate from (e.g. %struct.FRAME.matmul)? Compiling simple Fortran code with DragonEgg: > cat matmul.f90 subroutine matmul(nx, ny, nz) implicit none integer :: nx, ny, nz real, dimension(nx, ny) :: A real, dimension(ny, nz) :: B real, dimension(nx, nz) :: C integer :: i, j, k real,

Hi, All I want to implement DSWP Which is used for parallelization of loops. For this purpose, the loop was replaced with a new basic block in main function. And new functions were created and basic blocks of Loop assigned to them.I have checked blocks and branches for Succ and Pred relation and I have not found any problems. However I get the following error: * **opt:

Dear LLVM, Consider two loops with one interation - First with constant lower bound, second with usual non-constant lower bound: int main(int argc, char ** argv) { int numOfIterations= 1; int stride=1; int lowerBound = 1000; - 1st | int lowerBound = argc; - 2nd int upperBound = lowerBound + (numOfIterations - 1)*stride; int i = lowerBound;

Hi, I haven't been able to reproduce this problem on a smaller test and the original source code is from another virtual machine's IR. What I found out was that 42 << 7 is actually DPSoRegImmFrm, defined in ARMInstrFormats.td. This format is not dealt with in the ARMCodeEmitter.cpp and that's the problem I'm facing. The triple I'm using is

On Mon, Feb 27, 2012 at 9:30 AM, Benjamin Kramer <benny.kra at googlemail.com> wrote: > > On 27.02.2012, at 17:13, Николай Лихогруд wrote: > >> Dear LLVM, >> >>     Consider two loops with one interation - >>     First with constant lower bound, second with usual non-constant lower bound: >> >>     int main(int argc, char ** argv) >>     {

On 27.02.2012, at 17:13, Николай Лихогруд wrote: > Dear LLVM, > > Consider two loops with one interation - > First with constant lower bound, second with usual non-constant lower bound: > > int main(int argc, char ** argv) > { > int numOfIterations= 1; > int stride=1; > int lowerBound = 1000; - 1st | int lowerBound =

We have several optimizations in InstCombine for bitwise logic ops (and/or/xor) that fail to handle compare patterns with the equivalent bitwise logic. Example: define i8 @or_and_not(i8 %a, i8 %b) { %nota = xor i8 %a, -1 %and = and i8 %nota, %b %res = or i8 %and, %a ret i8 %res } define i1 @or_and_cmp_not(i32 %a, i32 %b, i1 %c) { %cmp = icmp sgt i32 %a, %b %cmp_inv = icmp sle i32 %a,

This can't be an instsimplify though? The values we want in these cases do not exist already: %res = or i8 %b, %a %res = or i1 %cmp, %c On Thu, Jul 13, 2017 at 5:10 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Thu, Jul 13, 2017 at 2:12 PM, Sanjay Patel <spatel at rotateright.com> > wrote: > >> We have several optimizations in InstCombine

Hi Guillermo, I’m unable to reproduce the error you’re seeing with your bitcode input. “llc –mtriple armv7a-unknown-linux-gnueabi –O3” succeeds. What are you using to reproduce, and what version? Cheers, James From: Guillermo Perez [mailto:gaperez64 at gmail.com] Sent: 20 February 2012 11:32 To: James Molloy; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] ARM opcode format Hi, I haven't

On Thu, Jul 08, 2004 at 08:06:29PM +0400, Vladimir Prus wrote: > Could anybody quickly explain why PHI nodes instructions are necessary > in machine code? And why the code in LiveVariables.cpp which looks at > those PHI nodes (line 249 and below) is necessary. LLVM Machine code is in SSA. Let's say you want to do r = a cond b But doing this: if (a cond b) then r = 1

I was thinking about this last night, and I came up with a third alternative which I think looks very promising. It’s basically a re-working of the previous alternative to use the landingpad concept rather than arbitrary fake logic, but it uses a single landing pad for the entire function that mimics the logic of the personality function to dispatch unwinding calls and catch handlers. I believe

Hi! I'm having some trouble with a pass I'm writing. I'm using DemotePHIToStack to remove all phi node in my code with this code (this is the first thing I do in my pass): // Erase phi node vector<PHINode*> phis; for (Function::iterator i=f->begin();i!=f->end();++i) { for(BasicBlock::iterator b=i->begin();b!=i->end();++b) {

Hi, I'm sorry I forgot to mention I am compiling the bitcode using the JIT. The actual error, I get when I'm trying to get the function to the pointer. I'm using a custom front end that translates Android's Dalvik bytecode into LLVM bitcode based on Android ICS's modified LLVM version. Thanks, On Mon, Feb 20, 2012 at 7:55 PM, James Molloy <James.Molloy at arm.com>

Could anybody quickly explain why PHI nodes instructions are necessary in machine code? And why the code in LiveVariables.cpp which looks at those PHI nodes (line 249 and below) is necessary. The reason I'm asking is that I try to support 64-bit comparison and I do it by generating code like: // if high1 cond high2: goto operand0 // if high1 reverse_cond high2:

On 27.02.2012, at 18:49, Eli Friedman wrote: > On Mon, Feb 27, 2012 at 9:30 AM, Benjamin Kramer > <benny.kra at googlemail.com> wrote: >> >> On 27.02.2012, at 17:13, Николай Лихогруд wrote: >> >>> Dear LLVM, >>> >>> Consider two loops with one interation - >>> First with constant lower bound, second with usual

I have developed a pass to instrument LLVM bit code files with calls to a custom instrumentation library. For one of the instrumentation calls, I need to pass the name of the temporary variable used in LLVM bit code. For example, if I see LLVM assembly code as shown below, %13 = icmp eq i64 %11, 0, !dbg !14 After the instrumentation pass, it needs to look like the following %13 = icmp eq i64

In your original file, %6 is defined in if.end11 and is used in cond.end. if.end11 branches to cond.true and cond.false, both of which branch unconditionally to cond.end. Therefore %6 dominates its use. In your second file %18 is defined in end.11 and used in cond.end. However, end.11 no longer dominates cond.end because you have rewritten all branches to go through the switch statement in

Hi Reid, Thanks for the input. You wrote: > The @_Z4testv.unwind.1 helper just calls ~Inner(), but not ~Outer. That’s actually intentional. The thing to keep in mind is that all of the landing pads are going to be effectively removed by the time the final object image is generated. They are just there to facilitate the table generation, and in the __CxxFrameHandler3 case they don’t mean