Re: [RFA] New pass for sign/zero extension elimination

[Andrew Stubbs <ams@codesourcery.com>]

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