[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