[LLVMbugs] [Bug 410] NEW: Improvements in the MachineInstr/Operand classes

[bugzilla-daemon at cs.uiuc.edu]

http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=410

           Summary: Improvements in the MachineInstr/Operand classes
           Product: libraries
           Version: 1.0
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


This is a quick brain dump of things that I want to do to the code generator in
the LLVM 1.4 timeframe.

1. Move MachineOperand::regNum into the MachineOperand union, eliminate
   MachineOperand::Flags and MO_CCRegister.
2. Eliminate MachineInstr::numImplicitRefs.
3. Simplify and regularize the machineinstr/machine operand interface.
4. Make the MachineOperands vector part of the same memory object as the
   MachineInstr (reducing allocations and memory footprint).
5. Change how immediates and addressing modes are represented in MachineInstr
   (see below).
6. Dependent on #5, I want to start tablegen'ifying more of the code generators.  
   In the short term, the asmwriter should be produced by tablegen (Bug 280).
   In the longer term, the SparcV9 machine code writer should be generalized to
   support other architectures, and we should start looking at generating isels.
7. Investigate the feasibility of adding use/def and def/use information for
   vregs directly into the machine operands, like the LLVM representation has.

The changes I want to make to MachineOperand for immediates and addressing modes
are the most controversial.  In particular, I think that there should only be
two machine operand types for immediates (instead of 8): a simple integer
immediate, and a pointer to a MachineImmediate object.  The complex immediate
object is used when a complicated immediate is used by an MI (e.g., a global
variable address).

Because these objects are represented as external pointers, they can be dynamic
and extensible by the target.  This will allow us to support the equivalent of
the V9 HIFLAG32 (and friends) construct in a target-independent way (PPC and
others need this).  This is also a gateway towards a solution for Bug 283.

Addressing modes should be handled in a similar way.  In particular, the code
generator needs a new machine operand type for targets with "expressive"
addressing modes, like the X86.  In particular, we want the .td file for the
target to be able to describe the various addressing modes supported by the
target.  For targets that have simple addressing modes like Sparc and PPC, this
functionality would not be used.

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.