similar to: [LLVMdev] llvm-as and implicit value naming

On Sep 25, 2008, at 7:10 AM, Mark Shannon wrote: > Hi everyone, > > I don't know if this is a bug or I am misunderstanding things. > I couldn't find anything in the Bugzilla database. > > The following code: > > 1 @sp = external global i8** ; <i8***> > 2 > 3 define void @test(i8* %x) { > 4 entry: > 5 load i8*** @sp ; <i8**>:1 > 6

Hello List, I am working on creating periodograms from IP network traffic logs using the Fast Fourier Transform. The FFT requires all the data points to be evenly-spaced in the time domain (constant delta-T), so I have a step where I zero-pad the data. Lately I've been wondering if there is a faster way to do this. Here's what I've got: * data1 is a data frame consisting of

Hi, I have: ... @.str1 = private unnamed_addr constant [21 x i8] c"Now f is a function\0A\00", align 1 ; Function Attrs: ssp uwtable define i32 @_Z1fv() #2 { entry: %call = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([21 x i8]* @.str1, i32 0, i32 0)) ret i32 0 } Then I get after trying to erase the function from the module: 511

On 23 October 2013 22:41, Vassil Vassilev <vvasilev at cern.ch> wrote: > Hi, > I have: > ... > @.str1 = private unnamed_addr constant [21 x i8] c"Now f is a > function\0A\00", align 1 > ; Function Attrs: ssp uwtable > define i32 @_Z1fv() #2 { > entry: > %call = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([21 x > i8]* @.str1, i32 0,

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

Hi Tim, Thank you for that. I was just trying to replicate the branch instruction under a new opcode, so I don’t think that returns a value. Plus the code I was testing out didn’t have a br or my newly added instruction but it still threw that error at me. Here’s the IR code I tested: ; ModuleID = ‘cc.c’ source_filename = “cc.c” target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128”

On 2/25/11 1:50 PM, Kodakara, Sreekumar V wrote: > 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

Hi, 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, align 4 %26 = and i32 %25, 65535 store i32 %26, i32*

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

Nick, Unfortunately this doesn't answer my question I don't think. It seems that -instnamer, as you mention, names the instructions but still does not name the local variables. So there really is no way to do this shy of creating (or basically copying) the API from AsmWriter (seems very dedundant to me)? This seems like a large failing? On Fri, Oct 21, 2011 at 7:03 PM, Nick

Hiya, Is there any reason (and anything to worry about) if disk target IDs don''t start at 0 (zero). For some reason mine are like this (3 controllers - 1 onboard and 2 PCIe); AVAILABLE DISK SELECTIONS: 0. c8t0d0 <ATA -ST9160314AS -SDM1 cyl 19454 alt 2 hd 255 sec 63> /pci at 0,0/pci10de,cb84 at 5/disk at 0,0 1. c8t1d0 <ATA -ST9160314AS -SDM1

On 10/24/13 2:13 AM, Rafael Espíndola wrote: > On 23 October 2013 22:41, Vassil Vassilev <vvasilev at cern.ch> wrote: >> Hi, >> I have: >> ... >> @.str1 = private unnamed_addr constant [21 x i8] c"Now f is a >> function\0A\00", align 1 >> ; Function Attrs: ssp uwtable >> define i32 @_Z1fv() #2 { >> entry: >> %call =

Nick, Is there a clean way to tell the difference between dst and src operands in operations without assignment "=" (ie, store)? On Mon, Oct 24, 2011 at 9:52 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Nick, > > I forgot to thank you, thanks! > > > On Sat, Oct 22, 2011 at 2:25 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > >> Ryan

Hi again. I have a complex type system in my custom language that isn't easily representable as LLVM IR types, so I figured I could mostly get along with treating my types as i8* and doing the appropriate bitcasts and inttoptr instructions, and doing pointer arithmetic myself (by casting the pointers to ints, adding the appropriate byte offsets, and then casting back to pointers). However,

Hi Bill, With the latest llvm version I'm getting the following error: opt -instnamer < core-device.c.bc > core-device.o.bc Attribute 'nobuiltin' only applies to functions! void (%struct.fw_csr_iterator*, i32*)* @fw_csr_iterator_init Broken module found, compilation aborted! 0 opt 0x0000000001914bf1 llvm::sys::PrintStackTrace(_IO_FILE*) + 38 1 opt

Thanks for the answers. Although I am not sure if I've understood the docs about how inttoptr/ptrtointr are different when compared to gep. It says: "It’s invalid to take a GEP from one object, address into a different separately allocated object, and dereference it.". To go back to my intention why I am doing this, I would like to "emulate" some x86 instructions with

This code is generated for va_arg. %6 = getelementptr inbounds %struct.__va_list_tag* %5, i32 0, i32 3 ; <i8**> [#uses=1] %7 = load i8** %6, align 8 ; <i8*> [#uses=1] %8 = getelementptr inbounds [1 x %struct.__va_list_tag]* %ap, i64 0, i64 0 ; <%struct.__va_list_tag*> [#uses=1] %9 = getelementptr inbounds %struct.__va_list_tag* %8, i32 0, i32 0 ;

Thank you for the hint. I adjusted the code and it works: The code after replacing inttoptr with getelementptr: define { i32, i32, i8* } @test(i32 %foo, i32 %bar, i8* %sp) { entry: ; push foo (On "stack") %sp_1 = getelementptr i8, i8* %sp, i32 -4 %sp_1_ptr = bitcast i8* %sp_1 to i32* store i32 %foo, i32* %sp_1_ptr, align 4 ; push bar %sp_2 = getelementptr i8, i8* %sp_1,

Hi, guys! I write a virtual machine which uses LLVM as back-end code generator. The following function code causes strange "UNREACHABLE executed!" error: define void @p1(%1*) { %2 = call i8* @llvm.stacksave() %3 = alloca %0 %4 = getelementptr %0* %3, i64 1 %5 = ptrtoint %0* %3 to i64 %6 = ptrtoint %0* %4 to i64 %7 = sub i64 %6, %5 %8 = bitcast %0* %3 to i8* call void