similar to: [LLVMdev] How are callees resolved?

On Feb 12, 2008, at 5:26 PM, Chuck Rose III wrote: > Hola LLVMers, > > I’m debugging through some strangeness that I’m seeing on X64 on > windows with LLVM2.2. I had to change the code so that it would > engage the x64 target machine on windows builds, but I’ve otherwise > left LLVM 2.2 alone. The basic idea is that I’ve got a function bar > which is compiled by

Hey Evan, At the point of the instructions you suggested I step through, X86ISelLowering has this state: - this 0x00000000005fe728 {VarArgsFrameIndex=-842150451 RegSaveFrameIndex=-842150451 VarArgsGPOffset=3452816845 ...} llvm::X86TargetLowering * const + llvm::TargetLowering {TM={...} TD=0x00000000008edac0

Hola LLVMers, I'm debugging through some strangeness that I'm seeing on X64 on windows with LLVM2.2. I had to change the code so that it would engage the x64 target machine on windows builds, but I've otherwise left LLVM 2.2 alone. The basic idea is that I've got a function bar which is compiled by VStudio and I'm creating another function foo via LLVM JIT which is going

On Mon, 11 Apr 2005, dummy1 at boxpl.com wrote: >> There are many possible ways to do this, can you be a bit more specific >> about what you're trying to do? > Here is a basic example: Ah, ok, I see what you're trying to do. Below is some *pseudo* code for the basic idea: > ============================================ > unsigned int buff[4096]; > > int main

On Sun, 15 Jul 2007, Paolo Invernizzi wrote: > First, I'm not sure if deleting the ExecutionEngine is all I need to > clean-up... so I started with a minimal test just to check Is this llvm 2.0 or llvm svn head? Several minor memory leaks have been fixed since llvm 2.0. -Chris > int main( int argc, char **argv ){ > while( true ){ > Module *M = new

First, I'm not sure if deleting the ExecutionEngine is all I need to clean-up... so I started with a minimal test just to check int main( int argc, char **argv ){ while( true ){ Module *M = new Module("M"); Function *F = cast<Function>(M->getOrInsertFunction("F", Type::Int32Ty, (Type*)0)); BasicBlock *BB = new

I'm trying to set up some automated testing, and I'd like to have multiple instances of ExecutionEngines, so that the state from the first test doesn't alter the second state. Right now I'm doing something along the lines of: Module *emptyModule = new Module("emptyModule"); ExecutionEngine executionEngine = ExecutionEngine::create(emptyModule);

On Sun, 2005-04-10 at 19:47 -0500, Chris Lattner wrote: > On Mon, 11 Apr 2005, Paul wrote: > > I'm trying to pass an array pointer to my run-time generated module, and > > after a long time of searching for the answer, the only thing I got was > > a headache. Basically I have a few arrays (few megabytes which will > > sometimes be accessed as 8 / 16 / 32 / 64 bit

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

Hi Kirill, Don't forget to add X86TargetMachine.obj (add to Additional Dependencies in Linker options, if you are using MSVS) otherwise LLVM will try and use Interpreter instead of JIT. Hope this helps, Rob. > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of kirill havok > Sent: Wednesday, August 20, 2008

kirill havok wrote: > Hi Gordon, > I wrote a small example, but while running I get an error("Tied to > execute an unknown external function"), where I am wrong? > I think the problem is that some_test_func() is a C++ function, so its name is being mangled during compilation. To fix it, I think you want to add a declaration telling the compiler to treat some_test_func()

Reid, Thanks! You were right! Changing the code to: float (*theF)(float) = (float (*)(float)) EE -> getPointerToFunction(f); float retVal = theF(arg1); made the difference. Now it is dozens of times faster! I don't really understand the cause though.. Why doesn't ExecutionEngine cope well with "define float @someFunc(float %x)" and needs this trick ? (but copes well with

Apologies for the noop question in advance (just getting started with LLVM), and I'm not entirely sure if this is the right list to post to. is it? I have some lambda functions as member variables that I want to have my LLVM language make calls to. I've added a mapping to them, but this doesn't seem to enable LLVM to resolve the functions. I asked on stackoverflow but the suggestion

Hello, I'm not sure what I am trying to do is possible. I'm trying to create two modules, and call a function in one module from another module. First, a reassurance that I'm not trying to do something completely off the wall would be nice as I don't see any tutorials that do this. Second, any help getting this to work would be wonderful. Thanks, Aaron In my code, you'll

Probably because the integer version of the prototype is special-cased. The problem is that the JIT has a C function pointer of an arbitrary type that it only finds out about at runtime. Normally, if you call a function pointer with a known type, your compiler will generate the proper calling code and allocate the arguments in registers or on the stack. However, doing that inside the JIT would

Hi Gordon, I wrote a small example, but while running I get an error("Tied to execute an unknown external function"), where I am wrong? Thanks in advance. Kirill. int some_test_func( int ){ std::cout << "!!!!" << std::endl; return 8848; } int _tmain(int argc, _TCHAR* argv[]){ Module *M = new Module("test"); ExistingModuleProvider* MP = new

> > > My bet is that your code is writing through a stray pointer. By > > > removing the call to InitializeNativeTarget you are simply hiding > > > your bug by running the code within a context that turns its effects > harmless. > > > > > > OTOH, LLVM 2.9 may be the culprit. In any case, it is time for a > > > assembler- level debug session

Ok, here's the new patch. (Please tell me if I shouldn't mail patches directly on the mailing list.) While I was editing LowerGC.cpp I made a little test (not part of this patch, but the diff with LowerGC.cpp in cvs is attached). I've added a new intrinsic called llvm.gcroot_value(sbyte*, sbyte*), which takes a pointer directly instead and transforms it into an alloca. The idea is the

On Wed, 21 Jul 2004, Chris Lattner wrote: > > Yes, this makes a tremendous amount of sense. Do you think you could > prepare some patches to make this happen? If you have any questions, feel > free to ask :) Ok, a patch[1] is attached. I didn't care to coerce the offset, since I assume that it is an uint, but maybe I should? Hopefully I've understood the llvm source

Bill, That is great to hear. I must be doing something wrong. When I try to do this, I get ERROR: Program used external function 'myLinkedFunction' which could not be resolved! Because of its brevity, I use getOrInsertFunction when I am creating calls to the function in module A. I use new llvm::Function(type, llvm::Function::ExternalLinkage, "myLinkedFunction", moduleB)