If getClobberingMemoryAccess() is called with an explicit MemoryLocation, but the starting access happens to be a call, the provided location is currently ignored, and alias analysis queries will be performed against the call instruction instead. Change the implementation to always use the location if provided, and only use the call for IsCall queries.
Okay, I'm pretty sure this is not fixing the right issue. If I'm understanding correctly, the real problem is that the provided memory location just gets ignored entirely if the UseInst happens to be a call. I think whether AA is queried with the location or with the call should be determined by Query.IsCall, not whether UseInst is a call.
Depends on what you mean by "comes from" :) This is indeed the place where we create a Query with IsCall=false and Inst being (potentially) a CallBase. However, I believe this is correct, as this query should only care about the provided Loc, not the Inst it happens to start at. Maybe it would be possible to set Inst to nullptr altogether...
Even after this fix, there will still be an issue with the handling of loads, due to this code. Say we start from a store and perform a clobber query on getDefiningAccess(), which happens to return a volatile load. Then we will end up trying to find clobbers for the volatile load, once again ignoring the provided location completely.
Set Inst to nullptr to prevent any abuse, thus handling both the call and the load case. Also drop the special lifetime.start handling so that clobbers between calls and lifetime.start are correctly handled.