vsk added a comment.
@dblaikie thanks for chasing that down & the detailed explanation.
It's unfortunate that introducing call site info affects the line table. The
impact of the change seems somewhat neutral (the additional line 0 locations
aren't //wrong//, exactly), so I'm not sure it's worth keeping track of all the
labels //just// referenced by call site tags and teaching DwarfDebug to tiptoe
around those. As you point out, perhaps the divergence could be reduced by some
general (hypothetical) improvement w.r.t line 0 locations for spill code. That
might be the cheaper option (IIRC there's a predicate available on
`MI.getPseudoValue()` to check for a spilled value).
I'm going to hold off on landing this, though. We've just gotten an internal
report about some KAsan code that trips:
inlinable function call in a function with debug info must have a !dbg
location
%134 = call i8* @__asan_memcpy(i8* %agg.tmp2.sroa.0.0..sroa_cast10.i, i8*
%agg.tmp.sroa.0.i.0..sroa_cast, i64 32)
Apparently there's a `#define memcpy __asan_memcpy` in some system-internal
KAsan header, and some pass (likely ASan) introduces __asan_memcpy calls
without attaching debug info. So we'll have to fix that first.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D69970/new/
https://reviews.llvm.org/D69970
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
