I tried this patch for AMD GCN. We have a similar problem with excess
extends, but also for vector modes. Each lane has a minimum 32 bits and
GCC's normal assumption is that vector registers have precisely the
number of bits they need, so the amdgcn backend patterns have explicit
sign/zero extends for QImode and HImode for the instructions that might
need it. It would be cool if this pass could eliminate some of those,
but at this point I just wanted to check it didn't break anything.
Unfortunately I get a crash building libgcc:
during RTL pass: ext_dce
conftest.c: In function 'main':
conftest.c:16:1: internal compiler error: RTL check: expected code 'subreg',
have 'reg' in ext_dce_process_uses, at ext-dce.cc:421
16 | }
| ^
0x8c7aa3 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
/scratch/astubbs/omp/upA/gcnbuild/src/gcc-mainline/gcc/rtl.cc:770
0xa76a27 ext_dce_process_uses
/scratch/astubbs/omp/upA/gcnbuild/src/gcc-mainline/gcc/ext-dce.cc:421
0x1aeca5c ext_dce_process_bb
/scratch/astubbs/omp/upA/gcnbuild/src/gcc-mainline/gcc/ext-dce.cc:651
0x1aeca5c ext_dce
/scratch/astubbs/omp/upA/gcnbuild/src/gcc-mainline/gcc/ext-dce.cc:802
0x1aeca5c execute
/scratch/astubbs/omp/upA/gcnbuild/src/gcc-mainline/gcc/ext-dce.cc:868
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
configure:3812: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/";
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
I have no idea if this is an unhandled case or a case that shouldn't
exist, but it's trying to do "SUBREG_BYTE (dst).is_constant ()" for a
very simple instruction:
(set (reg/i:SI 168 v8)
(const_int 0 [0]))
This seems pretty basic to me, but there is some hidden complexity. It's
possible that the pass has correctly identified that "v8" can hold more
that just a single integer: in this case we're using a single lane of a
vector register. No extend is needed here though. The register has 2048
bits, but only 32 are active in SImode.
Andrew
