[LLVMdev] No more TargetFlags on MO_Register MachineOperands

Tom Stellard thomas.stellard at amd.com
Wed Aug 22 11:44:17 PDT 2012


On Wed, Aug 22, 2012 at 11:41:17AM -0700, Owen Anderson wrote:
> 
> 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.
> 

Would it work to add a new Operand subclass to tablegen called
InstrFlagOperand (or something similar) that had a DefaultOps member, like
PreidcateOperand and OptionalDefOperand?

-Tom

> --Owen
> 




More information about the llvm-dev mailing list