Displaying 6 results from an estimated 6 matches for "andn64rr".
Did you mean:
andn32rr
2013 Mar 21
0
[LLVMdev] Simpler types in TableGen isel patterns
...types in TableGen isel patterns
>
> Currently, instruction selection patterns are defined like this:
>
> def : Pat<(and (not GR32:$src1), GR32:$src2),
> (ANDN32rr GR32:$src1, GR32:$src2)>;
> def : Pat<(and (not GR64:$src1), GR64:$src2),
> (ANDN64rr GR64:$src1, GR64:$src2)>;
>
> TableGen infers the types of $src1 and $src2 from the specified
> register classes, and that is the only purpose of the register
> classes in a pattern like that. SelectionDAG doesn't really
> understand register classes, it only uses types.
>...
2013 Mar 21
9
[LLVMdev] Simpler types in TableGen isel patterns
Currently, instruction selection patterns are defined like this:
def : Pat<(and (not GR32:$src1), GR32:$src2),
(ANDN32rr GR32:$src1, GR32:$src2)>;
def : Pat<(and (not GR64:$src1), GR64:$src2),
(ANDN64rr GR64:$src1, GR64:$src2)>;
TableGen infers the types of $src1 and $src2 from the specified register classes, and that is the only purpose of the register classes in a pattern like that. SelectionDAG doesn't really understand register classes, it only uses types.
If I try to constrain the r...
2013 Mar 21
1
[LLVMdev] Simpler types in TableGen isel patterns
...gt; >
> > Currently, instruction selection patterns are defined like this:
> >
> > def : Pat<(and (not GR32:$src1), GR32:$src2),
> > (ANDN32rr GR32:$src1, GR32:$src2)>;
> > def : Pat<(and (not GR64:$src1), GR64:$src2),
> > (ANDN64rr GR64:$src1, GR64:$src2)>;
> >
> > TableGen infers the types of $src1 and $src2 from the specified
> > register classes, and that is the only purpose of the register
> > classes in a pattern like that. SelectionDAG doesn't really
> > understand register classes,...
2013 Mar 21
0
[LLVMdev] Simpler types in TableGen isel patterns
...t 2pi.dk> wrote:
> I think in most cases it would be much simpler and safer to specify pattern types directly:
>
> def : Pat<(and (not i32:$src1), i32:$src2),
> (ANDN32rr i32:$src1, i32:$src2)>;
> def : Pat<(and (not i64:$src1), i64:$src2),
> (ANDN64rr i64:$src1, i64:$src2)>;
>
> This doesn't lose any type checking because the register classes of the instructions in the output pattern are still checked. It avoids the problem where type inference makes it impractical to add types to a register class to model instruction set extensio...
2013 Mar 21
0
[LLVMdev] Simpler types in TableGen isel patterns
...esen <stoklund at 2pi.dk>wrote:
> Currently, instruction selection patterns are defined like this:
>
> def : Pat<(and (not GR32:$src1), GR32:$src2),
> (ANDN32rr GR32:$src1, GR32:$src2)>;
> def : Pat<(and (not GR64:$src1), GR64:$src2),
> (ANDN64rr GR64:$src1, GR64:$src2)>;
>
> TableGen infers the types of $src1 and $src2 from the specified register
> classes, and that is the only purpose of the register classes in a pattern
> like that. SelectionDAG doesn't really understand register classes, it only
> uses types.
>...
2013 Mar 23
0
[LLVMdev] Simpler types in TableGen isel patterns
...esen <stoklund at 2pi.dk>wrote:
> Currently, instruction selection patterns are defined like this:
>
> def : Pat<(and (not GR32:$src1), GR32:$src2),
> (ANDN32rr GR32:$src1, GR32:$src2)>;
> def : Pat<(and (not GR64:$src1), GR64:$src2),
> (ANDN64rr GR64:$src1, GR64:$src2)>;
>
> TableGen infers the types of $src1 and $src2 from the specified register
> classes, and that is the only purpose of the register classes in a pattern
> like that. SelectionDAG doesn't really understand register classes, it only
> uses types.
>...