[PATCH] D60831: [DebugInfo at O2][LoopVectorize] pr39024: Vectorized code linenos step through loop even after completion

[John Mellor-Crummey via Phabricator via llvm-commits]

jmellorcrummey added a comment.



> A good example for why arbitrarily picking one location during merging is when the two locations are coming from different inlined instances of different functions (or perhaps even worse: two inlined instances of the same function). I would assume that even in profiling a wrong backtrace would invalidate or render untrustworthy large parts of any analysis being done one this data.

I think we fundamentally disagree on what is good for profiling. If for instance two "load" instructions from different inlined contexts merge, I would prefer that they be charged to one of the locations where the instruction came from and the other gets the benefit of that operation for free. (That's what common subexpression elimination is for!) Saying that one got merged into the other or vice versa is an acceptable view. I don't see this as misleading, untrustworthy, or invalidating anything.

If the instructions come from two different files, I guess that you won't even associate it with one of the files. So, I have instructions in the binary that won't be covered by line map entries at all. Having LITERALLY NO INFORMATION where they came from without tracing instruction generation through the compiler is something that I fundamentally oppose.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60831/new/

https://reviews.llvm.org/D60831