Following from the previous patch in this series which adds the DIArgList metadata, allowing us to reference multiple Value pointers, this patch updates DbgVariableIntrinsics to make use of this functionality, resulting in a significant change to its interface.
This patch is not intended to update all IR passes to handle dbg.values with multiple location operands; that is being left to the next patch in the stack. This patch simply updates DbgVariableIntrinsic to handle DIArgLists, and updates code elsewhere to use the new interface. In some cases these changes are immediately valid, but in many they are not. All code outside of the intrinsics themselves assumes that an intrinsic will always have exactly one location operand; they will still support DIArgLists, but only if they contain exactly one Value.
Among other changes, the setOperand and setArgOperand functions in DbgVariableIntrinsic have been made private. This is to prevent code from setting the operands of these intrinsics directly, which could easily result in incorrect/invalid operands being set. Obviously this does not prevent these functions from being called on a debug intrinsic at all, as they can still be called on any CallInst pointer. My assumption however is that any code that is looking at a generic pointer without examining the type is going to be conservative about setting the operands to arbitrary values, and in any case where we could safely do so for any CallInst, we can safely do so for a DbgVariableIntrinsic. The intention for making these functions private is to prevent DIArgLists from being overwritten by code that's naively trying to replace one of the Values it points to, and also to fail fast if a DbgVariableIntrinsic is updated to use a DIArgList without a valid corresponding DIExpression.
Maybe this isn't such a big deal, but this function has a weird UI now — returning a SmallVector with nullptrs... I wonder if we should instead return a small iterator object? How is this used?