On Monday 13 July 2009 15:46, Chris Lattner wrote:> Well sure, but how is that relevant? Just generate llvm.stoppoint and > isel turns them into debug locs. Just because debugloc isn't on > llvm::Instruction doesn't mean you don't get line numbers :).You're right, it's not a big hurdle.> > Ok, here's an example: > > > > movl (%rsi), %ecx # LLVM > > Instruction: volatile store i32* %ksize, i32** %ksize3 ; > > [oox.4 : sln.5] > > > > # > > [result] Pattern > > 1367 > > Instead of printing 1367, why not print "MOV32rm" like -print- > machineinstr does? If you really want 1367, just print MI- > > >getOpcode(). The asmprinter definitely has this information.Ok, I wasn't aware of that at the time I did this stuff. Printing the pattern name is even better!> > I forgot about the LLVM instruction information. That's something > > that can't > > be synthesized by the asmprinter. Again, we only emit some of this > > with > > special debug flags so we don't carry the original IR around in > > comments all > > the time. :) > > Sure, I understand that comments in general only get turned on with > something like -fverbose-asm. But where/how do you expect this > information to be propagated onto the machineinstrs?Some comments are on all the time, but those I think we can do with asmprinter, as you suggest. I have patches that propagate comments from Instructions to SDNodes to MachineInstrs. Again, after answering the FI stack slot question, the IR-level instruction information is the only thing we can't do through asmprinter. I'm open to other ways of capturing the information that don't require comments in MachineInstrs. But the information has to be stored somewhere. This IR instruction stuff isn't a huge priority for us. It's helpful when debugging but the TableGen information is way more important. I wouldn't cry too much if we can't get the IR instruction information in right now.> For now, lets go forward with the plan of having the asmprinter > generate the comments. It sounds like it can cover at least 75% of > what you're interested in, and the other cases probably have better > solutions that sticking a vector of std::string on MachineInstr.That's ok by me. Let's hash through this some more as stuff comes on-line. -Dave
On Jul 13, 2009, at 1:58 PM, David Greene wrote:>>> Ok, here's an example: >>> >>> movl (%rsi), %ecx # LLVM >>> Instruction: volatile store i32* %ksize, i32** >>> %ksize3 ; >>> [oox.4 : sln.5] >>> >>> # >>> [result] Pattern >>> 1367 >> >> Instead of printing 1367, why not print "MOV32rm" like -print- >> machineinstr does? If you really want 1367, just print MI- >> >>> getOpcode(). The asmprinter definitely has this information. > > Ok, I wasn't aware of that at the time I did this stuff. Printing the > pattern name is even better!Oh, also, if it's not clear :), I'm really excited by this work. Making the .s files more readable would be a huge quality of life improvement for many people working on the code generator!> >>> I forgot about the LLVM instruction information. That's something >>> that can't >>> be synthesized by the asmprinter. Again, we only emit some of this >>> with >>> special debug flags so we don't carry the original IR around in >>> comments all >>> the time. :) >> >> Sure, I understand that comments in general only get turned on with >> something like -fverbose-asm. But where/how do you expect this >> information to be propagated onto the machineinstrs? > > Some comments are on all the time, but those I think we can do with > asmprinter, as you suggest.Yep.> I have patches that propagate comments from Instructions to SDNodes to > MachineInstrs. > Again, after answering the FI stack slot question, the IR-level > instruction > information is the only thing we can't do through asmprinter. I'm > open to > other ways of capturing the information that don't require comments in > MachineInstrs. But the information has to be stored somewhere.Ok, lets deal with this as a separate pass. A good solution may be to have an on-the-side DenseMap<MachineInstr*,Instruction*>.>> For now, lets go forward with the plan of having the asmprinter >> generate the comments. It sounds like it can cover at least 75% of >> what you're interested in, and the other cases probably have better >> solutions that sticking a vector of std::string on MachineInstr. > > That's ok by me. Let's hash through this some more as stuff comes > on-line.Thanks Dave! -Chris
On Monday 13 July 2009 16:03, Chris Lattner wrote:> Oh, also, if it's not clear :), I'm really excited by this work. > Making the .s files more readable would be a huge quality of life > improvement for many people working on the code generator!Yes, the whole reason this stuff exists is that I needed to improve my quality of life at the time. :) -Dave
On Monday 13 July 2009 15:58, David Greene wrote:> Again, after answering the FI stack slot question, the IR-level instruction > information is the only thing we can't do through asmprinter. I'm open to > other ways of capturing the information that don't require comments in > MachineInstrs. But the information has to be stored somewhere.Ugh. I just found another case I don't think we can synthesize in asmprinter. We mark rematerialized instructions as well so our performance guys don't come and ask us why we didn't hoist saomething out of a loop. :) We're also a bit more expressive in our spill/reload marking. For example, we're mark whether a spill or reload was merged with another instruction and mark copy instructions that were inserted because the spiller could reuse a previous reload. These are all extra things the spiller inserts. We might be able to get folded spill/reload information synthesized by looking at MachineOperands but I don't think we can get reuse copies or rematted values. Would it be acceptable to add a small flags field to MachineInstr that we can use as a bitvector? -Dave
On Tuesday 14 July 2009 15:35, David Greene wrote:> Would it be acceptable to add a small flags field to MachineInstr that we > can use as a bitvector?In fact I think I can put a short between the NumImplicitOps and the Operands fields and not increase MachineInstr size on most architectures. -Dave
On Tuesday 14 July 2009 15:35, David Greene wrote:> On Monday 13 July 2009 15:58, David Greene wrote: > > Again, after answering the FI stack slot question, the IR-level > > instruction information is the only thing we can't do through asmprinter. > > I'm open to other ways of capturing the information that don't require > > comments in MachineInstrs. But the information has to be stored > > somewhere. > > Ugh. I just found another case I don't think we can synthesize in > asmprinter. We mark rematerialized instructions as well so our performance > guys don't come and ask us why we didn't hoist saomething out of a loop. > :)Here's another question. If we mark StackObjects as spill slots, isn't it possible that stack slot coloring could come along and assign non-spill/reload memory objects to the same slot? If so, it would appear we really do need a flag on MachineInstr to notate all spills and reloads. -Dave