similar to: [LLVMdev] Instantiating modules from .bc files

Hi Danny, On 2007-12-26, at 15:39, Danny wrote: > I've noticed that the BitcodeReader appears to be an internal > module, but the BitstreamReader is public. Should I be using the > BitstreamReader? If so how. The generic BitstreamReader class is public because it's used in other projects, including clang, to serialize data structures other than LLVM IR. The coding of

That worked quite well. Thank you. One question as a follow up: is there a nice/standard way of including the pre-made bitcode chunks in with the binaries that are being created which read them? Bascially, I'd like to have the same functionality, but rather than having one or more .bc files running around which need to be read at runtime by an executable, moving that into the code

Hi LLVM-ers, I am trying to get a return type of a function(from bitcode file) with LLVM-C API, but there seems no appropriate API to do that. I've tried to do that with following code, ---- LLVMModuleRef M; LLVMMemoryBufferRef MemBuf; LLVMValueRef F; // Function LLVMTypeRef RetTy; char *ErrStr; // // -- Load shader module //

Hello everyone: I have a little question about the second argument *action* of verifyFunction. In docs: *Enumerator: * *AbortProcessAction* verifyModule will print to stderr and abort() *PrintMessageAction* verifyModule will print to stderr and return true *ReturnStatusAction* verifyModule will just return true But it still abort when I pass

Hi Xiu, The Verifier pass runs a PreVerifier pass, which does not honour the action argument, and will always abort on a broken module, (Line 106, lib/VMCore/Verifier.cpp) Perhaps you should file a bug against this, to allow you to not abort if you so wish. Joey On 11 June 2012 09:41, Guowei Xu <myesis at gmail.com> wrote: > Hello everyone: > > I have a little question

Hi, I stumbled across the following: > /* Builds a module from the bitcode in the specified memory buffer, > returning a > reference to the module via the OutModule parameter. Returns 0 on success. > */ > LLVMBool LLVMParseBitcode2(LLVMMemoryBufferRef MemBuf, > LLVMModuleRef *OutModule); However in most scenarios i know, a Bool is something like 0 = False !0 = True In short:

Hello, Following the tutorial "Kaleidoscope: Adding JIT and Optimizer Support", I found a Segmentation fault when I try to execute it. I am new in the neighbourhood, so I don't know what is wrong. Could you help me with that? I am working with the last version of LLVM (2.5). The code in chapter 2 and 3 works good, but the code in the chapter 4 did not work. Below are the detail of

Hi Óscar, Thank you for your prompt reply. Unfortunately, I still need more guidance as using the Demo page to generate C++ code didn't result in a global variable being used. Basically, I'm following your advice to use a LoadInst: Value *v = new LoadInst(result, "", theBasicBlock); Function *myfn = cast<Function>(v); I was not sure how I could get a BasicBlock for the

FWIW, I'm also suddenly experiencing segfaults in code that used to work a few days ago (I'm using svn). This may be unrelated to the problem described below, but perhaps it's the same thing. In my case it seems that creating an ExecutionEngine has changed. I used to do Module* Mod = makeLLVMModule(); // basically create a gcd function verifyModule(*Mod,

Hello, using the LLVM API, I've build one very simple function that adds two ConstantInts and returns the result. I noticed that, when I emit IR code, it is optimized to a simple "ret i16 42" when I add 40 and 2. I'd like to see the operations that are necessary to compute the result, though. Can I somehow disable this optimization in the pass, leading to more verbose IR code?

Of course, this is normal for C-APIs. But maybe change the name to LLVMResult to propagate the real use? I am not arguing about the results themself. They are standard. But the name is missguiding. As long as it's consistent i know that i have to write an extra record operator in Delphi to reflect this. 2016-09-12 11:11 GMT+02:00 David Chisnall <David.Chisnall at cl.cam.ac.uk>: > On

Hi All, I'm new to LLVM and I'm having a coding problem. I'm creating a GlobalVariable that contains a StructType that contains a Function. The function returns i32 and takes two i32's. Here is my code: GlobalVariable* retrieved = module->getGlobalVariable("myGV"); ... Constant* result = ConstantExpr::getGetElementPtr(retrieved, indices); How do I get my Function

Hi all, BitstreamReader is the only in-tree client of the DataStreamer and MemoryObject interfaces. In practice when using user-facing LLVM tools, the bitcode will normally either be in memory or in a file, so the best way to access it is through memory, either directly or memory mapped. As part of some refactorings I am making to BitstreamReader, I would like to simplify it by changing it to

Hello, Everyone I'm using llvm 3.6 DIBuilder module to build the debug information for Chapel language(the Chapel-llvm front end works fine). When I run the test program, I got these assertions failed: !718 Expected no forward declarations! !719 Expected no forward declarations! !720 Expected no forward declarations! !721 Expected no forward declarations! !722 All nodes should be resolved!

And on a separate thread [0] Derek indicated he'd be fine with removing it. I'll leave this thread open until end of Monday to receive any other opinions, then proceed to remove it. Peter [0] http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20161024/400754.html On Fri, Oct 28, 2016 at 10:08 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Hi all, > >

Hi Xiaoyi, this looks like a bug to me - please file a bug report. Ciao, Duncan. On 01/11/12 04:35, Guo, Xiaoyi wrote: > I have three modules: > ----------------------------------------------------------------- > s1.ll: > > %0 = type <{ i32, i32 }> > > define void @s1(%0* byval %myStruct) nounwind { > return: > ret void > } >

I have three modules: ----------------------------------------------------------------- s1.ll: %0 = type <{ i32, i32 }> define void @s1(%0* byval %myStruct) nounwind { return: ret void } ----------------------------------------------------------------- s2.ll: %0 = type <{ i32, i32 }> define void @s2(%0* byval %myStruct) nounwind { return: ret void }

Hi, I have the following IR code </snippet> %prev = getelementptr inbounds %struct.myStruct* %node, i32 0, i32 1 %1 = load %struct.myStruct** %prev, align 4, !tbaa !0 %next1 = getelementptr inbounds %struct.myStruct* %1, i32 0, i32 0 store %struct.myStruct* %0, %struct.myStruct** %next1, align 4, !tbaa !0 %2 = load %struct.myStruct** %prev, align 4, !tbaa ! </snippet> myStruct is

On Thu, Oct 25, 2012 at 3:15 PM, Pranav Bhandarkar <pranavb at codeaurora.org>wrote: > Hi, > > I have the following IR code > > </snippet> > %prev = getelementptr inbounds %struct.myStruct* %node, i32 0, i32 1 > %1 = load %struct.myStruct** %prev, align 4, !tbaa !0 > %next1 = getelementptr inbounds %struct.myStruct* %1, i32 0, i32 0 > store %struct.myStruct*

IRBuilder is a templated class, and one of the template arguments is the constant folder to use. By default it uses the ConstantFolder class which does target-independant constant folding. If you want to disable constant folding you can specify the NoFolder class instead, i.e. declare the builder as follows: IRBuilder<true, llvm::NoFolder> builder(body) On 26 Nov 2013, at 19:23, Daniel