search for: mutatetype

Function has its own FunctionType* member as well as a Type* member that it inherits from GlobalValue. The latter can be mutated but not the former, leading to potential strange inconsistencies. While I realize using mutateType is probably going to trigger a bunch of "you're doing it wrong" replies, it seems like mutateType, as a necessary evil, should be virtual and do the right wrong thing for Functions too. Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http...

...ule; 'new_return_type' denotes the duplicate of original function's return type; 'arg_types' denotes the duplicated argument type. And I have analysed the cause of error "Argument value does not match function argument type!" and I can determine that the error APIs are mutateType()(3rd line)or getArgumentList().insertAfter()(10th line) between LLVM3.5 and LLVM3.9. Anyone came across the same problem or knew the error API above? Thanks a lot! 1 unsigned address_space = func->getType()->getAddressSpace(); 2 FunctionType *new_type = FunctionType::get(ne...

Dear All, In my development, a function returns a struct {i8*, i64}, and on the call site I need to assign the return value to a struct of type {some_struct*, i64}. One way to do it is to call the mutateType() method of llvm::Value on the return value of the function call; however, I’m concerned that this mutateType() method might be too disruptive (it’s discouraged to use it by the documentation). Since LLVM does not support cast between structs. Is there any way I can safely “cast” a value of one str...

...); // two different ways depending on wether to create and insert or just create // AllocaInst *FDP_AI = new AllocaInst(cast<Type>(FDP_fatvector)); IRB.SetInsertPoint(AI); AllocaInst *FDP_AI = IRB.CreateAlloca(cast<Type>(FDP_fatvector)); cast<Value>(AI)->mutateType(cast<Value>(FDP_AI)->getType()); cast<Value>(AI)->replaceAllUsesWith(cast<Value>(FDP_AI)); } } I am getting an error at optimization time. After my pass ran, during the Bitcode Writer pass time: opt: /home/pierre/Desktop/llvm/lib/Bitcode/Writer/ValueEnumerator.h:162:...

...> > > 1) duplicate the LinkModule internal code and copy the module we load from > > bitcode to a new module with the correct types mapped. > > Sounds quite inefficient. If you have to duplicate the internal code > anyway, you can also iterate over the original module and mutateType(). > > > 2) duplicate BitcodeReader and create a version that reuses existing > > StructTypes. > > see below. > > > 3) destructively convert all of the types in the imported module to our > > existing types. > > That's what we actually implemented,...

...ven in the separate modules. > 1) duplicate the LinkModule internal code and copy the module we load from > bitcode to a new module with the correct types mapped. Sounds quite inefficient. If you have to duplicate the internal code anyway, you can also iterate over the original module and mutateType(). > 2) duplicate BitcodeReader and create a version that reuses existing > StructTypes. see below. > 3) destructively convert all of the types in the imported module to our > existing types. That's what we actually implemented, following the idea I described in the mentioned p...

...you propably would have >> to use the name, or attach other metadata to uniquely identify your structs. > > I was actually fearful of this approach, it looked to me like the linker was > at least partially copying data structures to the destination module. I see > that there is a mutateType() method in Value, though it comes with a very > stern warning :-) Yeah, but as long as you mutate all types consistently, it works quite smoothly. The Verifier will tell you which values you missed ;) You shouldn't forget - function arguments - initializers of global variables - constant...

...[EXT] [llvm-dev] Cast between struct >> >> Dear All, >> >> In my development, a function returns a struct {i8*, i64}, and on the call >> site I need to assign the return value to a struct of type {some_struct*, >> i64}. >> One way to do it is to call the mutateType() method of llvm::Value on the >> return value of the function call; however, I’m concerned that this >> mutateType() method might be too disruptive (it’s discouraged to use it by >> the documentation). >> Since LLVM does not support cast between structs. Is there any way I...

Hi all, We've run into a tricky situation in our work on the Crack compiler and I'm hoping that someone on this list can help us find the best solution. We're currently trying to implement "module caching" for Crack, similar to the feature in Python where module bitcode is persisted at compile time. When we import a module, before compiling the module we check for a

Hi all, I would like my optimization pass to change an object's address space that is created by llvm.lifetime.start intrinsic. Because I want to be able to identify them later in a codegen pass. I can get a pointer from the intrinsic using CallInst::getArgOperand() function. However, I don't know what to do with it (or if it is the pointer that I want). How can I change its address space?

...ot this: Check function __cxa_pure_virtual Call parameter type does not match function signature! %6 = load %class.A** %a, align 4 %class.B* call void @_ZN1B4testEi(%class.A* %6, i32 1) Ok! I've tried to change the first %class.A %6 to %class.B %6 by "FirstArgumentOfCS->get()->mutateType(FunctionFirstArgement->getType());", but in this case I've got this: Check function __cxa_pure_virtual Load result type does not match pointer operand type! %6 = load %class.A** %a, align 4 %class.A*Instruction does not dominate all uses! %6 = load %class.A** %a, align 4 %7 =...

...s of both modules to identify the types to unify. This leads to interesting effects in some cases, but I'll write another post about this. Nevertheless the TypeMapTy is a great piece of code, and we will definitely reuse it to remap duplicated types (and composed types) to unique ones (via mutateType(), recursively descending to all uses). > I have to ask: why are you writing these modules out as separate bc files? I knew that someone would ask that ;) We need to have separate modules during runtime. One of them contains the code that is actually JIT compiled and executed, and simultaneou...

Thank you Ahmad, I figured out that, although the type of both p(oInst) and p(nInst) were the same, I had to: for (unsigned int i = 0; i < callOInst->getNumArgOperands(); i++) { callOInst->getArgOperand(i)->mutateType(callNInst->getArgOperand(i)->getType()); } that solves the issue at the calling instruction in the main function, but now I see that *linkModules* does not work for me (it's a mess to bring all the other unnecessary functions from the reference module) so what I need is to directly move...

----- Original Message ----- > From: "Andrew Trick" <atrick at apple.com> > To: "Sanjoy Das" <sanjoy at playingwithpointers.com> > Cc: "Daniel Berlin" <dberlin at dberlin.org>, "llvm-dev" <llvm-dev at lists.llvm.org>, "Joseph Tremoulet" > <jotrem at microsoft.com>, "Oscar Blumberg"

...g> wrote: > >> Thank you Ahmad, >> >> I figured out that, although the type of both p(oInst) and p(nInst) were >> the same, I had to: >> >> for (unsigned int i = 0; i < callOInst->getNumArgOperands(); i++) { >> callOInst->getArgOperand(i)->mutateType(callNInst->getArgOperand(i)->getType()); >> } >> >> that solves the issue at the calling instruction in the main function, >> but now I see that *linkModules* does not work for me (it's a mess to >> bring all the other unnecessary functions from the reference...

...; 1. llvm::Instruction *nCloneInst = nInst->clone(); //Clone of the >> *nInst*, to avoid remove it from the refModule >> 2. nCloneInst->insertAfter(oInst); // I'll bring the nInst because I >> know *p(nInst)* and *p(nFunc)* match >> 3. nCloneInst->mutateType(oInst->getType()); //Idk why I have to >> this, but necessary for next line >> 4. oInst->replaceAllUsesWith(nCloneInst); >> 5. oInst->dropAllReferences(); >> 6. oInst->eraseFromParent(); >> >> Error: >> Instruction does not dominate...

...the *p(nFunc)*. 2. Second attempt: 1. llvm::Instruction *nCloneInst = nInst->clone(); //Clone of the *nInst*, to avoid remove it from the refModule 2. nCloneInst->insertAfter(oInst); // I'll bring the nInst because I know *p(nInst)* and *p(nFunc)* match 3. nCloneInst->mutateType(oInst->getType()); //Idk why I have to this, but necessary for next line 4. oInst->replaceAllUsesWith(nCloneInst); 5. oInst->dropAllReferences(); 6. oInst->eraseFromParent(); Error: Instruction does not dominate all uses! %0 = load i32, i32* %a, align 4 %2 = call i32 @foo3(...

...>>> >>>> I figured out that, although the type of both p(oInst) and p(nInst) >>>> were the same, I had to: >>>> >>>> for (unsigned int i = 0; i < callOInst->getNumArgOperands(); i++) { >>>> callOInst->getArgOperand(i)->mutateType(callNInst->getArgOperand(i)->getType()); >>>> } >>>> >>>> that solves the issue at the calling instruction in the main function, >>>> but now I see that *linkModules* does not work for me (it's a mess to >>>> bring all the other...

...tify the types to unify. > This leads to interesting effects in some cases, but I'll write another post > about this. > > Nevertheless the TypeMapTy is a great piece of code, and we will definitely > reuse it to remap duplicated types (and composed types) to unique ones (via > mutateType(), recursively descending to all uses). > >> I have to ask: why are you writing these modules out as separate bc files? > > I knew that someone would ask that ;) > We need to have separate modules during runtime. One of them contains the code > that is actually JIT compiled and...

On Jan 31, 2012, at 6:16 AM, Clemens Hammacher wrote: > This is because each module contains its own type table with all the types used in that module. When reading in the corresponding bitcode, the BitcodeReader explicitly calls StructType::create, without looking up in the context whether an equivalent type (even with the same name) already exists. > So I think that llvm is behaving