search for: fndescriptor

...d in g's module represent the same function, I think that I will have a problem latter. So, for the moment, I'm a little bit stuck with MCJIT. Something that could be really useful could be a mcjit that acts as a linker. If MCJIT could have a map like this (I give a pseudo-c++ code) class FnDescriptor { StringRef name; FunctionType fnType; LinkageType linkage; }; class FnState { llvm::Module* definedModule; /* maybe a llvm::ObjectImage* ? */ List<RelocationTable*>* users, void* currentPointer }; map<FnDescriptor, FnState> it could be really useful. Let's imagine t...

...d in g's module represent the same function, I think that I will have a problem latter. So, for the moment, I'm a little bit stuck with MCJIT. Something that could be really useful could be a mcjit that acts as a linker. If MCJIT could have a map like this (I give a pseudo-c++ code) class FnDescriptor { StringRef name; FunctionType fnType; LinkageType linkage; }; class FnState { llvm::Module* definedModule; /* maybe a llvm::ObjectImage* ? */ List<RelocationTable*>* users, void* currentPointer }; map<FnDescriptor, FnState> it could be really useful. Let's imagine t...

...e represent the same function, I think that I will have a problem latter. > > So, for the moment, I'm a little bit stuck with MCJIT. Something that could be really useful could be a mcjit that acts as a linker. If MCJIT could have a map like this (I give a pseudo-c++ code) > > class FnDescriptor { > StringRef name; > FunctionType fnType; > LinkageType linkage; > }; > > class FnState { > llvm::Module* definedModule; > /* maybe a llvm::ObjectImage* ? */ > List<RelocationTable*>* users, > void* currentPointer > }; > > map<FnDescript...

...the same function, I think that I will have a problem latter. > > So, for the moment, I'm a little bit stuck with MCJIT. Something that > could be really useful could be a mcjit that acts as a linker. If > MCJIT could have a map like this (I give a pseudo-c++ code) > > class FnDescriptor { > StringRef name; > FunctionType fnType; > LinkageType linkage; > }; > > class FnState { > llvm::Module* definedModule; > /* maybe a llvm::ObjectImage* ? */ > List<RelocationTable*>* users, > void* currentPointer > }; > > map<FnDescript...

...hink that I will have a problem latter. >> >> So, for the moment, I'm a little bit stuck with MCJIT. Something that >> could be really useful could be a mcjit that acts as a linker. If >> MCJIT could have a map like this (I give a pseudo-c++ code) >> >> class FnDescriptor { >> StringRef name; >> FunctionType fnType; >> LinkageType linkage; >> }; >> >> class FnState { >> llvm::Module* definedModule; >> /* maybe a llvm::ObjectImage* ? */ >> List<RelocationTable*>* users, >> void* currentPoi...

...problem latter. >>> >>> So, for the moment, I'm a little bit stuck with MCJIT. Something that >>> could be really useful could be a mcjit that acts as a linker. If >>> MCJIT could have a map like this (I give a pseudo-c++ code) >>> >>> class FnDescriptor { >>> StringRef name; >>> FunctionType fnType; >>> LinkageType linkage; >>> }; >>> >>> class FnState { >>> llvm::Module* definedModule; >>> /* maybe a llvm::ObjectImage* ? */ >>> List<RelocationTable*>...

Hi Andy, We had previous discussions about this, I'd like to state more exactly what features would make MCJIT a replacement for the JIT. After putting significant effort trying to move to MCJIT, I'm currently back with the JIT. This is in a REPL environment where functions are added and removed dynamically and response time is important. The issue is the legacy JIT provides great

...oblem latter. >>> >>> So, for the moment, I'm a little bit stuck with MCJIT. Something >>> that could be really useful could be a mcjit that acts as a linker. >>> If MCJIT could have a map like this (I give a pseudo-c++ code) >>> >>> class FnDescriptor { >>> StringRef name; >>> FunctionType fnType; >>> LinkageType linkage; >>> }; >>> >>> class FnState { >>> llvm::Module* definedModule; >>> /* maybe a llvm::ObjectImage* ? */ >>> List<RelocationTable*>...

...>> >>>> So, for the moment, I'm a little bit stuck with MCJIT. Something >>>> that could be really useful could be a mcjit that acts as a linker. >>>> If MCJIT could have a map like this (I give a pseudo-c++ code) >>>> >>>> class FnDescriptor { >>>> StringRef name; >>>> FunctionType fnType; >>>> LinkageType linkage; >>>> }; >>>> >>>> class FnState { >>>> llvm::Module* definedModule; >>>> /* maybe a llvm::ObjectImage* ? */ >>&gt...

...gt;> >>>> So, for the moment, I'm a little bit stuck with MCJIT. Something >>>> that could be really useful could be a mcjit that acts as a linker. >>>> If MCJIT could have a map like this (I give a pseudo-c++ code) >>>> >>>> class FnDescriptor { >>>> StringRef name; >>>> FunctionType fnType; >>>> LinkageType linkage; >>>> }; >>>> >>>> class FnState { >>>> llvm::Module* definedModule; >>>> /* maybe a llvm::ObjectImage* ? */ >>&gt...

Hi Gaël, I'm not familiar enough with the details of the old JIT engine and its event interface to comment on whether or not your changes are appropriate, but I'm not sure anyone is so the patch is probably OK as is. I don't see any obvious problems with it. However, your description of the changes raises a bigger issue in my mind. I'm not sure if you are aware of this, but