[llvm] r181463 - Add line tracking support to FormattedStream

[Chris Lattner]

On May 21, 2013, at 10:08 AM, "Malea, Daniel" <daniel.malea at intel.com> wrote:
> DebugIR is a pass that replaces source-level debug metadata with metadata
> that points to the LLVM IR of the program that's being run so users can
> step through IR in LLDB or GDB. Here's a screenshot of stepping through
> some exception-catching machinery in GDB: http://i.imgur.com/OG6rUIE.png.
> Some folks who generate LLVM IR find this useful; it's been asked for
> repeatedly on the lists/IRC...

It looks really cute, but realize that it is a tool that only helps compiler hackers (they are the only ones who want to see LLVM IR).  Penalizing compile time (for example) for all clients is not the right tradeoff, a different implementation approach should be found.

> As for the slowdown this commit introduces, I have not measured it but I'd
> be happy to do so; is there a benchmark or use-case you've got in mind?

formatted_raw_ostream is used by .s file emission and .ll file printing (obviously :).  I don't really care about the speed of .ll printing (unless it becomes unreasonable), and we have an integrated assembler for most targets, so perhaps it isn't too bad.

> That said, nothing (except for DebugIR) really needs the line-counting
> functionality this commit adds to the stream class. I'd be happy to factor
> it out into a line_counting_formatted_raw_ostream class if you'd prefer to
> have formatted_raw_ostream count only columns as it did before.

I don't really want to have super-fine grained classes either.  :-)  It seems that there are two reasonable options here:

1) Just change formatted_raw_ostream as you have done.
2) Refactor DebugIR to emit IR to a temporary buffer, then ad-hoc reparse the generated buffer to  get the information you want.

#2 seems better from a conceptual standpoint (it slows down DebugIR generation, but nothing else suffers).  However, given that there are only two clients of the formatted stream, and neither of them are performance critical, #1 is nice and simple and already done.

Ok ok, I retract my objection about FormattedStream, thanks for tolerating me. :-)

-Chris