llvm dev - Aug 2012 - [LLVMdev] No more TargetFlags on MO_Register MachineOperands

> -----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,
> 
> On Aug 21, 2012, at 11:21 AM, Tom Stellard <thomas.stellard at
amd.com>
> wrote:
> 
> > I've been working on replacing the MachineOperand flags in the
R600
> > backend with immediate operands, but I can't figure out how to
modify
> > the instruction patterns to make this work.  For example, I have the
> class:
> >
> > class R600_1OP <bits<32> inst, string opName, list<dag>
pattern,
> >                InstrItinClass itin = AnyALU> :
> >  InstR600 <inst,
> >          (outs R600_Reg32:$dst),
> >          (ins R600_Reg32:$src, R600_Pred:$p, i32imm:$flags),
> >          !strconcat(opName, " $dst, $src ($p)"),
> >          pattern,
> >          itin
> >> ;
> >
> > And an instruction def:
> >
> > def CEIL : R600_1OP <
> >  0x12, "CEIL",
> >  [(set R600_Reg32:$dst, (fceil R600_Reg32:$src))]
> >> ;
> >
> > Tablegen fails to compile this with an error: "Operand $flag does
not
> > appear in the instruction pattern"
> >
> > Is there some way I can have this pattern initialize the $flag
> operand
> > to 0?
> 
> 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.
> --Owen
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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
>

> -----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