This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RFC: generic vectors and GPR/simd duality


Hi folks.

The following test, distilled from execute/simd-1.c is failing on the
E500.  This test uses 16 byte simd operations, but the E500 only has 8
byte simd operations.

	typedef int __attribute__((vector_size (16))) vecint;
	vecint i, k;
	 
	int main () {
	  k = -I;
	}
		
Optabs synthesizes the 16-byte operation from a pair of V2SI
operations, which the e500 does have.  Reload, however, is having a
hell of a time with the awkward e500 registers.

We start with:

    (insn 14 13 15 (set (subreg:V2SI (reg:V4SI 123) 0)
            (neg:V2SI (reg:V2SI 124))) -1 (nil)
        (nil))

The register allocator gives GPR #26-#30 for the V4SI mode above:

     (insn 14 13 17 0 (set (subreg:V2SI (reg:V4SI 26 26 [123]) 0)
             (neg:V2SI (reg:V2SI 0 0 [124])))

Then we die in subreg_offset_representable_p():

   #ifdef ENABLE_CHECKING
     if (offset % GET_MODE_SIZE (ymode)
         || mode_multiple % nregs_multiple)
       abort ();
   #endif

mode_multiple from V2SI to V4SI is 2, whereas nregs_multiple is 4.
GPR #26 can hold a V2SI in just one register, but needs 4 for a V4SI.
In other architectures, a given SIMD register can hold only one type
of simd, whereas the e500 can hold any (albeit in subsequent registers
for anything not V2SI).  Confusion.

Can someone more reload savvy point me in the right direction here?
Should we avoid making these subregs in the first place (way back in
optabs)?  Or is some reload wizardry required?

Cheers.
Aldy


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]