On Monday 13 August 2007 15:50, Chris Lattner wrote:> > I also have a few questions on the general design of AsmPrinter. Why is > > runOnMachineFunction implemented for each target AsmPrinter? I would > > Historical reasons that aren't very good. Over the years, I've taken > several stabs at merging the asmprinters from various targets together. > They used to be completely separate with no common base class for example. > Any progress to merging them further would be great. :)Ok, I'll see what I can do. :)> > have expected this to live in the base AsmPrinter class with calls out to > > specialized helper functions (Template Method pattern). If things were > > designed this way, it would be trivial to do what I want: > > Yes, this is one advantage, another is that we wouldn't have to fix the > same bug in multiple places :)Right. I've figured out where I need to make the changes in AsmWriterEmitter given the current design. I'm trying out a few interesting things here based on custom streambufs. It requires some surgery to AsmPrinters as a std::ostream won't work anymore due to the enhanced functionality of the custom streambufs. Is this still interesting to the larger LLVM community? One thing I have to do is figure out how to handle asm dumps to cerr. -Dave
On Tue, 14 Aug 2007, David Greene wrote:>> Yes, this is one advantage, another is that we wouldn't have to fix the >> same bug in multiple places :) > > Right. I've figured out where I need to make the changes in AsmWriterEmitter > given the current design.Ok, cool.> I'm trying out a few interesting things here based on custom streambufs. > It requires some surgery to AsmPrinters as a std::ostream won't work > anymore due to the enhanced functionality of the custom streambufs. > Is this still interesting to the larger LLVM community? One thing I have > to do is figure out how to handle asm dumps to cerr.It really depends on what you mean. I've found that iostreams are extremely slow, much slower than C stdio streams. Eventually I'd like to move them to stdio, not to more complex streambufs :) -Chris -- http://nondot.org/sabre/ http://llvm.org/
On Wednesday 15 August 2007 11:32, Chris Lattner wrote:> > I'm trying out a few interesting things here based on custom streambufs. > > It requires some surgery to AsmPrinters as a std::ostream won't work > > anymore due to the enhanced functionality of the custom streambufs. > > Is this still interesting to the larger LLVM community? One thing I have > > to do is figure out how to handle asm dumps to cerr. > > It really depends on what you mean. I've found that iostreams are > extremely slow, much slower than C stdio streams. Eventually I'd like to > move them to stdio, not to more complex streambufs :)Basically, what I've done is augment basic_streambuf to keep track of columns and provide manipulators that use this ability to set the output at a specific column (by padding with spaces if necessary). This makes it easy to line up comments, for example. This would be quite a bit uglier with C stdio. For example: // Custom streambuf (pseudo-llvm APIs) instr->print(O); O << comment("Place after instruction"); // C stdio int current_column = instr->print(outfile); printComment(current_column, "Place after instruction"); This means that every ::print/::dump/etc API that's used to print asm has to track columns by parsing output strings and looking for newlines and tabs. With a custom streambuf it's automatic. There's value to this whole newfangled encapsulation thing. :) As for performance, I guess I haven't seen a huge issue. The compilation time is spent in the optimization, not in the asm output. Right now the custom streambuf is only used to print asm. I don't see a reason to use it elsewhere. Of course, other kinds of custom streambuf can be useful. I once wrote a circular-buffering streambuf that was great for dumping debug output. At program termination the streambuf dumped that last N lines of output sent to it. So you didn't get gobs of debug output when all you really cared about was what happened toward the end. -Dave
On Wed, 2007-08-15 at 09:32 -0700, Chris Lattner wrote:> On Tue, 14 Aug 2007, David Greene wrote: > >> Yes, this is one advantage, another is that we wouldn't have to fix the > >> same bug in multiple places :) > > > > Right. I've figured out where I need to make the changes in AsmWriterEmitter > > given the current design. > > Ok, cool. > > > I'm trying out a few interesting things here based on custom streambufs. > > It requires some surgery to AsmPrinters as a std::ostream won't work > > anymore due to the enhanced functionality of the custom streambufs. > > Is this still interesting to the larger LLVM community? One thing I have > > to do is figure out how to handle asm dumps to cerr. > > It really depends on what you mean. I've found that iostreams are > extremely slow, much slower than C stdio streams. Eventually I'd like to > move them to stdio, not to more complex streambufs :)Eventually I'd like to move them to native syscalls adapted by lib/System and suited to the purposes of compilers :) Reid.> > -Chris >