[LLVMdev] [PATCH] Support asm comment output
dag at cray.com
Mon Jul 13 13:58:16 PDT 2009
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
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.
More information about the llvm-dev