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

[Eric Christopher via llvm-commits]

On Wed, Nov 18, 2015 at 4:10 PM Paul Robinson <
Paul_Robinson at playstation.sony.com> wrote:

> probinson added a subscriber: wolfgangp.
> probinson added a comment.
>
> > that was removed a while back IIRC by (or because of) Paul
>
>
> "It was that way when I found it."
>
> Loading constants at the top of the (sub-)block, with no attached
> location, is how things stood when I took my first crack at it. Having the
> first instruction in a block inherit a source location from the tail of the
> physically preceding block is obviously not good. Attaching the original
> source location to the constant load isn't really better, because of the
> jumping-around thing.
>
>
Well, it is much better as it's only an issue if the same constant is used
multiple times in the block. As I said, it could also be updated to "newer"
locations any time it's used as well.


> My original patch had problems, which is one reason it didn't go in (or
> went in and came back out, I don't recall). We've been carrying it locally
> and most recently Wolfgang Pieb has been tweaking it.  I've cc'd him.
>
> I guess my real fundamental question is:  Why does FastISel work backwards
> from the end of the block anyhow?  I'm pretty sure we've seen cases where a
> bunch of constants get loaded up front, then there's so much register
> pressure that you start seeing spills.  Working forward from the beginning,
> constants would be loaded as they are needed, and can hang around for
> re-use later in the block without screwing up source location info.  I
> think we'd see less spilling and for sure the source location info would be
> smoother.
>

Fast-isel used to work from the top of the block, but it makes it much
harder to exit out of the compilation. If you look back in history you'll
see how much it sped things up and cleaned them up by going from the bottom
of the block.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151120/454fe773/attachment.html>