It's possible to segfault in DevirtModule::applyICallBranchFunnel when attempting to call getCaller on a call base that was erased in a prior iteration. This can occur when attempting to find devirtualizable calls via findDevirtualizableCallsForTypeTest if the vtable passed to llvm.type.test is a global and not a local. The function works by taking the first argument of the llvm.type.test call (which is a vtable), iterating through all uses of it, and adding any relevant all uses that are calls associated with that intrinsic call to a vector. For most cases where the vtable is actually a *local*, this wouldn't be an issue. Take for example:
define i32 @fn(ptr %obj) #0 {
%vtable = load ptr, ptr %obj
%p = call i1 @llvm.type.test(ptr %vtable, metadata !"typeid2")
call void @llvm.assume(i1 %p)
%fptr = load ptr, ptr %vtable
%result = call i32 %fptr(ptr %obj, i32 1)
ret i32 %result
}findDevirtualizableCallsForTypeTest will check the call base %result = call i32 %fptr(ptr %obj, i32 1), find that it is associated with a virtualizable call from %vtable, find all loads for %vtable, and add any instances those load results are called into a vector. Now consider the case where instead %vtable was the global itself rather than a local:
define i32 @fn(ptr %obj) #0 {
%p = call i1 @llvm.type.test(ptr @vtable, metadata !"typeid2")
call void @llvm.assume(i1 %p)
%fptr = load ptr, ptr @vtable
%result = call i32 %fptr(ptr %obj, i32 1)
ret i32 %result
}findDevirtualizableCallsForTypeTest should work normally and add one unique call instance to a vector. However, if there are multiple instances where this same global is used for llvm.type.test, like with:
define i32 @fn(ptr %obj) #0 {
%p = call i1 @llvm.type.test(ptr @vtable, metadata !"typeid2")
call void @llvm.assume(i1 %p)
%fptr = load ptr, ptr @vtable
%result = call i32 %fptr(ptr %obj, i32 1)
ret i32 %result
}
define i32 @fn2(ptr %obj) #0 {
%p = call i1 @llvm.type.test(ptr @vtable, metadata !"typeid2")
call void @llvm.assume(i1 %p)
%fptr = load ptr, ptr @vtable
%result = call i32 %fptr(ptr %obj, i32 1)
ret i32 %result
}Then each call base %result = call i32 %fptr(ptr %obj, i32 1) will be added to the vector twice. This is because for either call base %result = call i32 %fptr(ptr %obj, i32 1) , we determine it is associated with a virtualizable call from @vtable, and then we iterate through all the uses of @vtable, which is used across multiple functions. So when scanning the first %result = call i32 %fptr(ptr %obj, i32 1), then both call bases will be added to the vector, but when scanning the second one, both call bases are added again, resulting in duplicate call bases in the CSInfo.CallSites vector.
Note this is actually accounted for in every other instance WPD iterates over CallSites. What everything else does is actually add the call base to the OptimizedCalls set and just check if it's already in the set. We can't reuse that particular set since it serves a different purpose marking which calls where devirtualized which applyICallBranchFunnel explicitly says it doesn't. For this fix, we can just account for duplicates with a map and do the actual replacements afterwards by iterating over the map.
I don't think this is safe since when we eraseFromParent the instruction is deleted. Can we track a different way?