[llvm-dev] [RFC] Removing debug locations from ConstantSDNodes (original) (raw)

Vedant Kumar via llvm-dev llvm-dev at lists.llvm.org
Wed Oct 24 09:16:21 PDT 2018

On Oct 23, 2018, at 11:31 PM, Anton Korobeynikov via llvm-dev <llvm-dev at lists.llvm.org> wrote:

Sorry to resurrect the old thread – I completely missed it! On Thu, Jun 21, 2018 at 6:08 AM via llvm-dev <llvm-dev at lists.llvm.org> wrote:

+1. Constants are not inherently interesting, but loading one as an action preparatory to computing a value or setting up a parameter in a call, the instruction ought to be associated with the relevant source statement. And now we have a clear problem. I'm seeing many cases when such instruction got associated with the previous source statement which does not make any sense at all.

I see. The default behavior of the DWARF emitter is to reuse the previous location (within a basic block) for instructions without a location. If you need a quick workaround, you can use the cl::opt -use-unknown-locations=Enable to emit line 0 entries for constant materialization instructions. Note that this may significantly bloat line tables.

This happens because the constant now is location-less and therefore the location of such constant-materialization instruction is implicitly defined by the previous available location.

This seems to be quite a serious regression in the quality of the debug info produced by selection dag isel in LLVM 7 release as compared to LLVM 6.

What sorts of problems is this causing in practice? Would they be addressed by using line 0 locations?

My experience has been that this change resulted in significant improvements in the single-stepping & debugging experience for Swift users. I haven’t seen any new jumpy line table bugs when compiling with swiftc -Onone.

vedant

-- With best regards, Anton Korobeynikov Department of Statistical Modelling, Saint Petersburg State University

LLVM Developers mailing list llvm-dev at lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

More information about the llvm-dev mailing list