[llvm-dev] [RFC] Removing debug locations from ConstantSDNodes

Anton Korobeynikov via llvm-dev llvm-dev at lists.llvm.org
Fri Oct 26 12:04:16 PDT 2018


Hi Vedant,

> 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.
Right. And therefore it is not an option.

> What sorts of problems is this causing in practice? Would they be addressed by using line 0 locations?
First of all, line 0 is not an option because it significantly bloats
the line table.

> 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`.
The debug information now is simply incorrect due to change, because
we associate constants with wrong lines. Therefore everything which is
connected with line locations could be wrong:

1. If you put breakpoint on the particular line, e.g. a function call
with several constant arguments then the debugger will stop in the
middle of call sequence – after some of the constants already loaded.

Funny enough, sometimes we have proper line info for constans – if
regalloc choose to rematerialize the constant, then the location will
be properly inherited. This is why you probably have not seen much
problems on x86 where all the constants are trivially materializable.
The situation is different on e.g. ARM and AArch64 where e.g. not all
floating points constants could be trivially materialized.

2. I expect that the sampling-based profiling could be somehow affected as well.

Probably all these problems Paul had in mind when he said about
"backfilling" constants, but it seems there was no further follow-up.

I think that we need to revert this change and figure our the solution
that will yield correct debug info.

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


More information about the llvm-dev mailing list