similar to: [LLVMdev] Argument's types mismatch when creating CallInst.

On Fri, Nov 11, 2011 at 12:18 AM, arrowdodger <6yearold at gmail.com> wrote: > Hello. I have an .bc, which defines @foo(%type* arg1, %type* arg2, %type* > arg3). > Firstly, i do this: > > runtimeModule = getLazyIRFileModule("runtime.bc", smd, llctx); > > then this: > > fooFunction = runtimeModule->getFunction("foo"); > myType =

On Fri, Nov 11, 2011 at 11:00 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > A CallInst in one module can't reference a Function in another module. > Build a declaration of foo in the module where you're building the > call, and call that. > > -Eli > Hmm, before emitting any code i've added this:

Hello, I am trying to create IR block for making a call to function pointer. For creating the IR for a function call to "foo", with "foo" being defined as "void foo(int)", I can use the "getOrInsertFunction" call from Module class as follows: std::vector<Type*> FooArgs; FooArgs.push_back(IRB.getInt64Ty()); Value *FooFunction =

Hi Gael, I tried converting to your approach but I had some issues making sure that all symbols accessed by the jit modules have entries in the dynamic symbol table. To be specific, my current approach is to use MCJIT (using an objectcache) to JIT the runtime module and then let MCJIT handle linking any references from the jit'd modules; I just experimented with what I think you're doing,

Thanks for the pointers. Am I correct in assuming that putting the precompiled bitcode into a second module and linking (or using the object caches) would result in ordinary function calls, but would not be able to inline the functions? -- lg On Jan 21, 2014, at 11:55 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > I would say that the incompatibility is by design. Not

COM is not a language extension. It is a codification of a fairly obvious but not guaranteed C++ ABI/objectmodel decision. Specifically given C++: class Foo { public: virtual void Abc() = 0; virtual void Def() = 0; }; Foo* foo; foo->Abc(); what is the ABI in terms of C? Note well the "virtual" and "=0". They are important. COM declares

Hi Everyone, We are looking for advise regarding the proper use of LTO in conjunction with just-in time generated code. Our usage scenario goes as follows. 1. Our front-end generates an LLVM module. 2. A small runtime support library is linked-in. The runtime library is distributed as bitcode. It is generated using "clang++ -emit-llvm' and 'llvm-link'. This allows

Ok. I can make a copy of the unique_ptr before moving it into the builder's constructor and use the copy later on. It is confusing to require a unique_ptr. Frank On 09/14/2016 12:11 PM, Frank Winter via llvm-dev wrote: > I am constructing the engine builder in the following way: > > llvm::SMDiagnostic Err; > unique_ptr<Module> Mod = getLazyIRFileModule("f.ll",

I get a segfault with this code when setting the data layout: int main(int argc, char** argv) { llvm::InitializeNativeTarget(); llvm::LLVMContext TheContext; unique_ptr<Module> Mod(new Module("A",TheContext)); llvm::EngineBuilder engineBuilder(std::move(Mod)); std::string mcjit_error; engineBuilder.setMCPU(llvm::sys::getHostCPUName());

Thanks for the hindsight. I am currently working on a patch/potential fix which introduces a new Linker::ImportIntrinsicGlobalVariables flag. The patch includes a unit test reproducing the problem. Hopefully, that will help getting more feedback. Note that it might take a while before I am allowed to upload the patch since I need approval from Autodesk Legal department. Cheers, Benoit Benoit

Thanks Peter, this is very useful feedback. I did manage to change the behavior of LinkOnlyNeeded to correctly import all variables with AppendingLinkage. In fact, I discovered that there was already something fishy. A variable with AppendingLinkage would get imported correctly from the source module if the destination module already contained a definition for that variable and wouldn't be

Hi there, I am wondering how I can prevent the LLVM from re-ordering the added local variables during instrumentation? Because, during the instrumentation, I add some metadata to some local variables, exactly next to it, and the generated bitcode looks good. However, when it is executed, basically the stack is formed as all original local variables are located next to each other, and then all the

Hi Tim, Thanks for your reply. However, I have seen that addressSanitizer has done this by placing redzones around each local variable. But i have not figured out yet how they have done it, I was wondering if there is a switch or a method by which I can reset the slotNumbering given to each instruction. By doing so, LLVM would place them in the expected order I guess. Best regards, Saman On

Oh, I see. Regarding single stack allocation i am not sure how it is possible. For example for each local variable, I need to maintain a 4-byte metadata. for example, if it is a 4 bytes variable (e.i. int), I need to allocate 8, or if it is a struct, let's say 26 bytes, I need to allocate 30 bytes. How it is possible using AllocaInst? Thanks in advance On Fri, Sep 21, 2018 at 9:36 AM Tim

Hi Rafael, We will try out your patch and check to see how it will fit. You also talked about "It might be even possible to drop the requirement for the size to be known: Replace the call to AtEndOfStream by just trying to read more and checking if it failed, but that is a bit more than I wanted to do for this." That is to remove some calls to getSize()? Is there any expectation that

One question : "In the spirit of the (long-term) intent to migrate away from the SelectionDAG framework" .. is this meant in general or just in respect to legalization? On 04/24/2013 05:01 PM, Dan Gohman wrote: > In the spirit of the (long-term) intent to migrate away from the > SelectionDAG framework, it is desirable to implement legalization passes > as discrete passes.

In the spirit of the (long-term) intent to migrate away from the SelectionDAG framework, it is desirable to implement legalization passes as discrete passes. Attached is a patch which implements the beginning of a new type legalization pass, to help motivate discussion. Is LLVM IR the right level for this? The main alternative approach that's been discussed is to do FastISel to a

Hi Dan, Others have weighed in on the merits of IR vs MI legalization, I thought I'd chip in on a different area: + /// Legal roughly means there's a physical register class on the target + /// machine for a type, and there's a reasonable set of instructions + /// which operate on registers of this class and interpret their contents + /// as instances of the type. For