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

[David Blaikie via llvm-commits]

On Fri, Jan 15, 2016 at 11:36 AM, Frederic Riss via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

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


Yeah, I would share that concern (& in our case, care about the actual size
of the output, as much as we care about the speed of writing it 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
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160115/aa515f35/attachment.html>