Open Quuxplusone opened 3 years ago
Bugzilla Link | PR50035 |
Status | NEW |
Importance | P enhancement |
Reported by | Matt Arsenault (Matthew.Arsenault@amd.com) |
Reported on | 2021-04-19 17:59:15 -0700 |
Last modified on | 2021-04-19 19:12:17 -0700 |
Version | trunk |
Hardware | PC Linux |
CC | craig.topper@gmail.com, llvm-bugs@lists.llvm.org, llvm-dev@redking.me.uk, pengfei.wang@intel.com, spatel+llvm@rotateright.com |
Fixed by commit(s) | |
Attachments | |
Blocks | |
Blocked by | |
See also |
Is this related to the ConstrainForSubReg class in the EXTRACT_SUBREG handling
in InstrEmitter.cpp?
I recall we have these patterns split between 32-bit and 64-bit. I tried to
remove the COPY_TO_REGCLASS once, but it broke GlobalISel.
def : Pat<(i8 (trunc GR32:$src)),
(EXTRACT_SUBREG (i32 (COPY_TO_REGCLASS GR32:$src, GR32_ABCD)),
sub_8bit)>,
Requires<[Not64BitMode]>;
def : Pat<(i8 (trunc GR16:$src)),
(EXTRACT_SUBREG (i16 (COPY_TO_REGCLASS GR16:$src, GR16_ABCD)),
sub_8bit)>,
Requires<[Not64BitMode]>;
Do we need to add more COPY_TO_REGCLASS to more patterns?
(In reply to Craig Topper from comment #1)
> Is this related to the ConstrainForSubReg class in the EXTRACT_SUBREG
> handling in InstrEmitter.cpp?
This is essentially the same thing, yes. However GlobalISelEmitter just uses
the register constraints it knows and requests directly emitting a COPY with
the subreg index in the matcher table.
>
> I recall we have these patterns split between 32-bit and 64-bit. I tried to
> remove the COPY_TO_REGCLASS once, but it broke GlobalISel.
>
> def : Pat<(i8 (trunc GR32:$src)),
>
> (EXTRACT_SUBREG (i32 (COPY_TO_REGCLASS GR32:$src, GR32_ABCD)),
>
> sub_8bit)>,
>
> Requires<[Not64BitMode]>;
>
> def : Pat<(i8 (trunc GR16:$src)),
>
> (EXTRACT_SUBREG (i16 (COPY_TO_REGCLASS GR16:$src, GR16_ABCD)),
>
> sub_8bit)>,
>
> Requires<[Not64BitMode]>;
>
>
> Do we need to add more COPY_TO_REGCLASS to more patterns?
This is a bit ugly and I don't think should be needed. I think it would make
sense for tablegen to be smart enough to know to constrain the source register
class to be one compatible with the index, but that again would require
understanding this x86 specific hack in this case.
Are there only a small number of cases that need to worry about sub_8bit?
Are these patterns broken too?
def : Pat<(sra GR32:$src1, GR8:$src2),
(SARX32rr GR32:$src1,
(INSERT_SUBREG
(i32 (IMPLICIT_DEF)), GR8:$src2, sub_8bit))>;
def : Pat<(sra GR64:$src1, GR8:$src2),
(SARX64rr GR64:$src1,
(INSERT_SUBREG
(i64 (IMPLICIT_DEF)), GR8:$src2, sub_8bit))>;
def : Pat<(srl GR32:$src1, GR8:$src2),
(SHRX32rr GR32:$src1,
(INSERT_SUBREG
(i32 (IMPLICIT_DEF)), GR8:$src2, sub_8bit))>;
def : Pat<(srl GR64:$src1, GR8:$src2),
(SHRX64rr GR64:$src1,
(INSERT_SUBREG
(i64 (IMPLICIT_DEF)), GR8:$src2, sub_8bit))>;
def : Pat<(shl GR32:$src1, GR8:$src2),
(SHLX32rr GR32:$src1,
(INSERT_SUBREG
(i32 (IMPLICIT_DEF)), GR8:$src2, sub_8bit))>;
def : Pat<(shl GR64:$src1, GR8:$src2),
(SHLX64rr GR64:$src1,
(INSERT_SUBREG
(i64 (IMPLICIT_DEF)), GR8:$src2, sub_8bit))>;
(In reply to Craig Topper from comment #3)
> Are these patterns broken too?
I think these happen to work because they don't have a virtual register that
needs constraining, and instead copy to a specific physical register
Those shouldn't be going to a specific physical register. Those are the newer shift instructions that don't update flags and take shift amount from any register. Not the old ones that always used CL as the shift amount.