llvm dev - Aug 2012 - [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))>;

--Owen

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

--Owen