[PATCH] D42731: [IR] - Make User construction exception safe

Klaus Kretzschmar via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 15 06:33:41 PST 2018


kkretzsch added a comment.

Here is some additional information about the problem that this patch is intending to fix. Lets look at the construction of a CallInst instruction during IR generation:

static CallInst *Create(FunctionType *Ty, Value *Func, ArrayRef<Value *> Args, .. ){
...

return new (TotalOps, DescriptorBytes)    CallInst(Ty, Func, Args, Bundles, NameStr, InsertBefore);

}

CallInst::CalInst(Value* Func, ...) {
...
Op<-1>() = Func;
....
setName(name); // throws
...
}
Op<-1>() returns a reference to a Use object of the CallInst instruction and the operator=  inserts this use object into the UseList of Func. 
The same object is removed from that UseList  by calling the User::operator delete If the CallInst object is deleted. 
Since setName can throw a bad_alloc exception (if LLVM_ENABLE_EXCEPTIONS is switched on), the unwind chain runs into assertions ("Constructor throws?") in  
special  User::operator deletes operators:

- operator delete(void* Usr, unsigned)
- operator delete(void* Usr, unsigned, bool)

This situation can be fixed by simlpy calling the User::operator delete(void*) in these unimplemented  methods.

To ensure that this additional call succeeds all information that is necessary to calculate the storage pointer from the Usr address 
must be restored in the special case that  a sublass has changed this information, e.g. GlobalVariable can change the NumberOfOperands.


Repository:
  rL LLVM

https://reviews.llvm.org/D42731





More information about the llvm-commits mailing list