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. Something similar happens if the starting access is a load with a MemoryDef.
Change the implementation to not set Q.Inst in the first place if we want to perform a MemoryLocation-based query, to make sure it can't be turned into an Instruction-based query along the way...
Additionally, remove the special handling that lifetime.start intrinsics currently get. They simply report NoAlias for clobbers between lifetime.start and other calls, but that's obviously not correct if the other call is something like a memset or memcpy. The default behavior we get from getModRefInfo() will already do the right thing here.
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.