[llvm] [DebugInfo] Fix incorrect debug attribution for inlined allocas (PR #144345)

[Jeremy Morse via llvm-commits]

jmorse wrote:

Sorry for the very long delay, this sank a long way off my radar. Also sorry for the "I'm not sure" answer below,

The test originates from f60e0a160fc8db6, where "empty" source-location allocas were being assigned an inlining-call-site source location so that they'd have something useful, and then this was leaking into stack smashing protection. This patch goes further by dropping the source locations from any inlined allocas at all.

If my thinking's right, we've got two competing interests of:
 * The source location at any Instruction should be Good Enough (TM) for newly inserted instructions to inherit,
 * The source location of these allocas should be True (which is a long lexical distance from the start of the function).

Where the stack-protection code suffers from relying on the former but suffering the latter, plus it could technically be implemented differently.

IMO: we could chose either path here, either dropping the source locations on allocas or implementing the stack-protection code differently. Dropping alloca locations is more liberal and is more likely to lead to unexpected outcomes (but also might fix more behaviours than just this), while changing stack-protection is conservative. In fact, if we were going for technical rigour, we should do both. I suppose the best question is: do you @phyBrackets feel up to fixing some of the unexpected outcomes that might result from landing this patch?

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