[LLVMdev] [PATCH] Support asm comment output
clattner at apple.com
Mon Jul 13 11:13:21 PDT 2009
On Jul 13, 2009, at 10:02 AM, David Greene wrote:
>>> - Tag instructons with source line information (customers really
>>> want this).
>> Right, that would be nice. This should be synthesizable from the
>> DebugLoc on the instruction in the asm printer, no need to
>> encode it into the comment field.
> Except the DebugLoc stuff isn't all there yet AFAIK. We've been
> using the
> comment mechanism for over a year. I agree we should move to
> it from DebugLoc when it's ready.
> We're not going to submit our line number stuff anyway (it's too
> much of a
> hack) but we would like the comment infrastructure to be there.
DebugLoc is there. The transition isn't complete at the LLVM IR
level, but it is at the MachineInstr level AFAIK.
>>> - Tag instructions as register spills or reloads.
>> I'm not sure what this means exactly, but would it be sufficient for
>> the asmprinter to use isLoadFromStackSlot and print this if the FI is
>> a spill slot?
> Maybe. I'm not sure what information is available here. The other
> this code does is tag it as a vector or scalar spill/reload.
> that might be trickier as you have to take the opcode into account.
> It's a
> lot of work, at the very least.
Vector vs scalar should also be pretty simple, just look at the reg
class and the VT's involved. It should all be target independent,
probably less than a dozen lines. After the conversion to
formatted_raw_ostream, we can discuss the best way to do this. It
would be helpful if you gave an example of the output you wanted.
>>> - Tag instructions with an ID of the tblgen pattern that generated
>>> them. This
>>> is super useful for debugging.
>> this would also be really nice :). This can be generated by the asm
>> printer as well.
> How so? Where is the pattern information available?
You just want the name of the enum? This is the name field of the
TargetInstrDesc. If -print-machineinstrs has it, asmprinter can just
as easily :).
>>> - Tag instructions as top-of-loop, with nesting information (we use
>>> to do some static analysis on asm files).
>> What part of the code generator would identify this? It seems that
>> the asmprinter could do this, but it is less obvious than the former
>> ones. It also seems that this is really a basic block property, not
>> an instruction property.
> Yes, we tag basic blocks. That patch is coming later. I added a pass
> that explicitly examines loop information and adds the appropriate
> So this could be synthesized on-the-fly, I think.
Ok, my question is: "why in a separate pass instead of in the
asmprinter"? The idea is that comments inherently have no semantic
value, and they are only useful for the asmprinter backend. To reduce
complexity and compile time cost, it makes sense to do this stuff in
the asmprinter if feasible.
>> If these are the planned uses of the comments, it would be nice try
>> not add a per-machine-instr list of comments. Instead, the
>> could synthesize the list as it processes each instruction. This
>> makes the list of comments transient instead of persistent in the
>> machineinstrs. Does that sound reasonable to you?
> I still don't know how to synthesize tblgen pattern information in the
> asmprinter. Except line numbers, which we need today. Maybe all of
> the other
> current stuff can be synthesized. I don't know what might come down
> the road,
I don't know what you mean by "pattern information". We can obviously
enhance tblgen to include any information that we need, but I don't
see how the asmprinter wouldn't know something that an earlier pass
would. Again, it would be helpful if you included example output to
show what you're going for.
> What's the plan for meta-information? Could comments go there when
> ready? Would it be ok to add these for now and remove them as other
> mechanisms (DebugLoc, meta-information) come on-line?
Which meta-information, MDNode and friends? These won't really be per-
machine-instruction, so that won't help. There is a possibility that
we can add MD operands to machineinstrs, which might be sufficient for
your needs, but again it is unclear why you want to do any of this
stuff earlier than asmprinter.
More information about the llvm-dev