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

[Paul Robinson via llvm-commits]

probinson added a comment.

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.


FastISel is never going to hoist anything across basic-block boundaries.  It never looks at more than one block at a time.  FastISel is used only at -O0; would there ever be a post-ISel pass at -O0 that tried to do that kind of hoisting?

Conceptually, FastISel probably could do enough bookkeeping to be able to push a constant-materialization _down_ to the first use, which might be worth it just to save spills/restores. If the instructions did get pushed down to the first use, they could then be given the same debug loc as the use, which at least can't be any worse than things are now.

That would still potentially leave instructions at the top of the block that deal with phis, though, wouldn't it?  which kind of inherently don't have debug locations, so shuffling the local-value instructions around doesn't fully solve the top-of-block problem.


Repository:
  rL LLVM

http://reviews.llvm.org/D9887