[PATCH] D9887: [DebugInfo][FastISel] Prevent using debug location from previous block for local values

Frederic Riss via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 15 11:36:57 PST 2016


friss added a comment.

In http://reviews.llvm.org/D9887#327352, @echristo wrote:

> In http://reviews.llvm.org/D9887#327337, @dblaikie wrote:
>
> > (un-accept, didn't mean to override some of the thread context & I missed it while reading back over this - so going back to a "discussion" state)
> >
> > my basic thinking is: We know some instructions will never have locations on them (synthesized instructions for various reasons, etc) & if those instructions ever end up at the start of a block we'll probably get bad behavior (because they'll be assigned to whatever location is at the end of the block that happens to be laid out prior to this one) so we'll want this backpropagation regardless of any fixes we make to constants.
> >
> > Yes, putting single-use constants at their use would be nice/good/better (especially for things like asan), maybe even putting multi-use constants at their first use (is that always possible, though? do we ever propagate a constant load from two basic blocks into a common prior block for example?) if possible.
>


Note that I played with this a while ago and it's not trivial to get right. The biggest issue is that the generation of a local constant might trigger the generation of other constants that it depends on. So you have to do book keeping not at the instruction level, but by groups. I stopped working on it because I thought the added complexity (and I suppose runtime cost) didn't fit into FastISel.

> This is a pretty compelling argument, another thought is can we just assume line/column 0 on anything that doesn't have a location and actually use that in the output line table? Will gdb/lldb/other debuggers skip over things (this will help in the "what if we have a block with no instructions with locations on it" issue here) or will they do something silly?


While I really like the simplicity of that (if debuggers can cope), it means that the line table will have 0 entries at the beginning of most (I'm guessing the 'most' part here) basic blocks, which would make them much bigger (and thus slower to write out). If my fears are unfounded, then I think this 0 idea is by far the best compromise!


Repository:
  rL LLVM

http://reviews.llvm.org/D9887





More information about the llvm-commits mailing list