[LLVMdev] RFC: MachineInstr Annotations

David Greene dag at cray.com
Fri Jul 31 11:17:25 PDT 2009


I'm getting to the point where I want to contribute some more
MachineInstr comment support for things like spills.  As we've
discussed before, we don't have all of the information available
in AsmPrinter to synthesize the kind of comments that can be
helpful for debugging performance issues with register allocators
(our primary use for these kinds of comments).

In order to get this information to the AsmPrinter without requring
a lot of overhead, I'd like to propose adding a small bitvector to
MachineInstr to hold flags.  Something like this:

class MachineInstr : public ilist_node<MachineInstr> {
  const TargetInstrDesc *TID;           // Instruction descriptor.
  unsigned short NumImplicitOps;        // Number of implicit operands (which
                                        // are determined at construction 
time).

  unsigned short Flags;                 // ***NEW*** Various bits of info

  std::vector<MachineOperand> Operands; // the operands
  std::list<MachineMemOperand> MemOperands; // information on memory 
references
  MachineBasicBlock *Parent;            // Pointer to the owning basic block.
  DebugLoc debugLoc;                    // Source line information.

Adding Flags between NumImplicitOps and Operands shouldn't increase the size
of MachineInstr on most platforms due to alignment padding.

The kind of information I'd like to transmit via Flags is:

- This register-register copy is a result of a reload value being reused
  (i.e. it was inserted by the spiller).

- This spill was induced by some decision made by the allocator (ex. graph
  coloring choosing to speculatively color some node which caused a cascade 
  effect).

- This spill was forced by some debugging flag (this is coming in a later
  set of patches).

We could also mark instructions as spills but Chris has pointed out that we
can probably synthesize that in AsmPrinter with just a little bit of work.
The above information can't be inferred from stack layouts or anything else.

Thoughts?

                               -Dave



More information about the llvm-dev mailing list