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

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