[llvm] Fix performance bug in buildLocationList (PR #108886)

[Sriraman Tallam via llvm-commits]

tmsri wrote:

> Here the variable location covers the whole function except the last instruction -- perhaps there's a late variable assignment that's been optimised away. In this situation we want to issue a location list that covers the whole function except the final instruction, but I believe with this patch (and that extra clause of `RangeIt->second.EndLabel != Asm->getFunctionEnd()`) we'll instead emit a single-location location. That can then lead to a stale/out-of-date variable value being presented to the user on the final instruction of the program.
> 
> I might have missed something subtle about the labels though (I'm not familiar with basic-block sections, and it seems fiddly).

I did think of the case where the .loc only spans some subset of the entry section and there is another variable assignment that will cover the remaining subset of the entry section.  I think you are referring to this one, I am not sure what you mean by "optimised away" though, like there is an assignment but the .loc is missing? 

In this case, the values won't match between the first loc and the subsequent loc and the coalescing will not happen.

I will add an explicit test to cover this.  I understand your concern around that check, but I am unable to find a counter example that could violate it.   Let me refresh the patch with the new test case.  Thanks for taking a look!








https://github.com/llvm/llvm-project/pull/108886