similar to: Unknown Target Node

I'm still relatively new to llvm, good to know these errors are from CodeGen. On 03/03/19 10:49 AM, Tim Northover wrote: > On Sat, 2 Mar 2019 at 21:00, preejackie via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Could you please explain how you are using this? like commands >> >> When I run this IR in opt, it doesn't throw any errors. > The error

Hello everyone. I use this command clang -emit-llvm hello.c -c -o hello.bc llc hello.bc -march=mipsel -relocation-model=static -o hello.s to produce this MIPS code: .section .mdebug.abi32 .previous .file "hello.bc" .text .globl main .align 2 .type main, at function .set nomips16 # @main .ent main main: .cfi_startproc .frame $sp,32,$ra .mask 0x80000000,-4 .fmask

I'm attempting to modify a parser generator to emit LLVM code instead of C. So far the experience has been trivial, but I am now running into an error regarding labels that I can't seem to solve. Situation 1: A label is used immediately after a void function call (l6 in this case): <snip> %tmp26 = load i32* @yybegin, align 4 %tmp27 = load i32* @yyend, align 4 call void

Hi, I'm using LLVM 2.7 right now, and I found "opt -std-compile-opts" has missed some opportunities for optimization: define void @spa.main() readonly { entry: %tmp = load i32* @dst-ip ; <i32> [#uses=3] %tmp1 = and i32 %tmp, -16777216 ; <i32> [#uses=1] %tmp2 = icmp eq i32 %tmp1, 167772160 ; <i1> [#uses=2]

Hi, I have two problems regarding the llvm.stackrestore intrinsic. I'm running on 3.0, but a quick test on trunk also showed the same behavior. First problem: --------------- I have code like: tmp1 = call llvm.stacksave() tmp2 = alloca [do some stuff with tmp2] call llvm.stackrestore(tmp1) [some other stuff] tmp3 = call llvm.stacksave() tmp4 = alloca [do some stuff

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

On 2/22/11 1:31 PM, Arushi Aggarwal wrote: > Hi, > > I want to clone a given function, and add an argument to it. I then > want to add a call to that new function. I have a callInstruction CI, > which I want to transform to call this new function, and to take a new > argument. If I understand correctly, you're cloning the function first and then adding a new argument to

Hi, I tried creating intrinsics which are to be placeholders for a set of instructions which should not be executed by the backend. I want to retain only intrinsic,phi and terminator instructions in a basic block. I have taken care of the external dependencies of basic block. How do I delete the rest of the instructions? Thank You Aditya P.S:

Hi, I tried creating intrinsics which are to be placeholders for a set of instructions which should not be executed by the backend. I want to retain only intrinsic,phi and terminator instructions in a basic block. I have taken care of the external dependencies of basic block. How do I delete the rest of the instructions? Thank You Aditya P.S:

Hi, I want to clone a given function, and add an argument to it. I then want to add a call to that new function. I have a callInstruction CI, which I want to transform to call this new function, and to take a new argument. The code I added was as follows CI->getCalledFunction()->dump(); Function* DirectF = CloneFunction(CI->getCalledFunction());

Hi Bill, Thanks for working on this. Is there a reference for the function attribute uwtable, or is it to be defined as part of this effort? Thanks in advance Garrison On Jul 23, 2011, at 1:29, Bill Wendling wrote: > What? Yet another EH proposal?! This one is different from the others in that > I'm planning to start implementing this shortly. But I want your feedback! I've

The code sequence: > store %tmp1, var > > tmp4 = add %tmp3 , %tmp1 > can happen even if you eliminate the specific dag combine in question. The real solution lies elsewhere. To me, this seems more like a register allocation problem. Evan On Mar 22, 2009, at 9:39 PM, Alireza.Moshtaghi at microchip.com wrote: > I can't think of any workaround? this optimization eliminates

Hi, I'm trying to figure out why the following sequence of intructions is not collapsed to "ret i32 0" by the opt tool with "-03". --- %0 = type <{ i32* }> define i32 @main(%0* noalias nocapture %arg) nounwind readnone { bb: %tmp = alloca [1024 x i32], align 4 ; <[1024 x i32]*> [#uses=2] %tmp3 = getelementptr inbounds [1024 x i32]* %tmp, i32

The following piece of IR is a fixed point for opt -std-compile-opts/-O3: --- target datalayout = "e-p:64:64:64-S128-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f16:16:16-f32:32:32-f64:64:64-f128:128:128-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" target triple = "x86_64-unknown-linux-gnu" ; Function Attrs: nounwind readonly define i32 @get32Bits(i8*

Disabling this optimization in the DAG combiner isn't going to eliminate the problem; instcombine, GVN, and maybe even others also happen to perform this optimization. You may find it more effective to look for ways for codegen to recover in these kinds of situations. Dan On Mar 19, 2009, at 10:38 AM, Alireza.Moshtaghi at microchip.com wrote: > Some of the optimizations that the first

Remember, our target does not have registers like ordinary processors do. So register allocation is really not going to do much for us. What we have to do is to exploit the existing opportunities in the source code and try to generate code based on such opportunities. The dag combination in question is one such opportunity that is being destroyed by the optimization. You maybe right in that this

Some of the optimizations that the first DAG combine performs is counter productive for our 8-bit target. For example in: // I dropped the types because they are irrelevant. // Excuse me for changing the syntax... store %tmp1, %var %tmp2 = load %var %tmp4 = add %tmp3, %tmp2 Since load is the only user of var and since var has just be stored to, it assumes that %tmp1 is alive and it goes ahead

On Oct 27, 2013 2:16 PM, "David Nadlinger" <code at klickverbot.at> wrote: > > The following piece of IR is a fixed point for opt -std-compile-opts/-O3: > > --- > target datalayout = > "e-p:64:64:64-S128-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f16:16:16-f32:32:32-f64:64:64-f128:128:128-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"

Hi, I am trying to extract the name of the variables passed as an Argument to a Function. I am using a runOnFunction Pass. For example in the following IR respresentation, define void @foo(i32 %limit) { entry: -- -- } I should be able to walk the IR and get '%limit' as the external variable passed to the function. Another question, Is it possible to create a basic symbol table (

Hello all, I am instrumenting the code such that I write the results of some instructions to file. As you can see below, I am writing the results of add instruction to the file. The IR generated for writeToFile is also posted below. My problem is that it is writing to the file in format bytes and it is not human-readable. How do I make it write human readable strings to the file? define i32