[LLVMdev] No more TargetFlags on MO_Register MachineOperands

[Villmow, Micah]

> -----Original Message-----
> From: Owen Anderson [mailto:resistor at mac.com]
> Sent: Wednesday, August 22, 2012 11:41 AM
> To: Villmow, Micah
> Cc: Stellard, Thomas; llvmdev at cs.illinois.edu
> Subject: Re: [LLVMdev] No more TargetFlags on MO_Register
> MachineOperands
> 
> 
> On Aug 22, 2012, at 11:34 AM, "Villmow, Micah" <Micah.Villmow at amd.com>
> wrote:
> 
> >
> >
> >> -----Original Message-----
> >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-
> bounces at cs.uiuc.edu]
> >> On Behalf Of Owen Anderson
> >> Sent: Tuesday, August 21, 2012 11:37 AM
> >> To: Stellard, Thomas
> >> Cc: llvmdev at cs.illinois.edu
> >> Subject: Re: [LLVMdev] No more TargetFlags on MO_Register
> >> MachineOperands
> >>
> >> Tom,
> >>
> >> The generally accepted way of achieving this is to leave the built-
> in
> >> pattern on the instruction empty, and to use def : Pat constructs to
> >> provide the default values.
> >>
> >> def : Pat<(fceil R600_Reg32:$src), (CEIL R600_Reg32:$src, (i32 0))>;
> >>
> > [Villmow, Micah] Doing this for every instruction is unrealistic.
> 
> Not particularly.  There are backends already in existence that make
> heavy use of it.  The key is that def : Pat constructs can take
> advantage of all of the same mechanisms for factoring out commonality
> that normal patterns can, including multiclasses and ComplexOperands.
[Villmow, Micah] Can you provide example of it having to occur everywhere? The instruction enum list for my backend 6867 enums long and growing. Now the proposed solution is I have to write a pattern/duplicate every single instruction so I can add a literal operand for every register operand and an extra for every instruction. Instead of just providing 8-16 bits of information that the backend can do whatever it wants with, which seems like a much cleaner and simpler solution.
> 
> --Owen