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

[Vedant Kumar via llvm-dev]

vedant (sent from my iPhone)

> On Oct 26, 2018, at 12:04 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote:
> 
> 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 are the actual limits on the size of debug info in your uses cases? Do you surpass those limits with this option enabled?


>> 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.

If it solves your problem, I don’t see why not.


>> 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.

That happened before the change. All uses of a constant after the first would refer to the wrong line.


> 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.

Prior to the patch, you would jump to the first use of the constant, then jump back to the call...

That’s much, much worse.


> 
> Funny enough, sometimes we have proper line info for constans – if
> regalloc choose to rematerialize the constant, then the location will
> be properly inherited.

That only happens if the constant doesn’t have a location.


> 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.

I double checked this with sample pgo folks earlier in the thread.

Again, the situation was much worse without this patch. Say you take a sample and see constant materialization code. If that code has a location associated with the first use of a constant, you’re marking the wrong block hot.


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

I pointed out various problems with the backfilling scheme. Happy to hear a workable idea.


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

This would be a major regression for stepping behavior, and I don’t think we should do that.

best,


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