PING^3 for PR target/17836, PR c/10735, PR c++/16882, PR rtl-optimization/17860[3.4]

[Janis Johnson]

On Wed, Nov 24, 2004 at 12:05:52PM -0500, David Edelsohn wrote:
> 	Darwin and PPC64 Linux always define altivec_abi, so those target
> configurations have not generated warnings.  The new warnings are from
> 32-bit PowerPC Linux, where one can use -maltivec without -mabi=altivec to
> generate Altivec code within a function while avoiding passing and
> returning Altivec vectors.

powerpc64-linux with -m64 supports "-maltivec -mabi=no-altivec" for the
same reasons you give for supporting that in powerpc-linux.

It's important to have some kind of warning for passing and returning
vector values (to real functions, not builtins) with -mabi=no-altivec to
warn the user that there are compatibility issues.

>                              The Altivec intrinsics can confuse GCC and
> generate incorrect warnings.

How is the ABI relevant for AltiVec builtins?  The warnings for
passing and returning synthetic vectors from user-defined funtions
should not apply to calls to AltiVec builtins.

> 
> 	rs6000_pass_by_reference has included code to pass Altivec vectors
> by reference when altivec_abi was not defined.  That prevented warnings
> with the new warning code.  rs6000_return_in_memory did not have any
> matching behavior.  This patch adds an equivalent exception to
> rs6000_return_in_memory so that it reverts to the original behavior,
> apparently returning in GPRs.

Will this be documented in the relevant ABIs?

> 	In both the original rs6000_pass_by_reference code and the new
> rs6000_return_in_memory code, the GCC vector types will not map to Altivec
> vector modes unless -maltivec is enabled.  This specifically is handling
> the case of
> 
> 	TARGET_ALTIVEC && !TARGET_ALTIVEC_ABI
> 
> without explicitly testing TARGET_ALTIVEC.  That is what the
> rs6000_pass_by_reference always has done.  This patch only makes
> rs6000_return_in_memory consistent with that behavior.
> 
> 	This patch also changes the warning from using the term "synthetic
> vector" to "GCC vector" as discussed on IRC.

"GCC vectors" is not any more clear than "synthetic vectors", and I'm
still very confused about just what they are.  I see the classes of
vectors as

  generic vectors
    types defined at the source level that are compiled into either
    hardware-supported vectors or synthetic vectors

  hardware-supported vectors
    generic vectors that map to vector types supported by the target
    hardware when compiled with appropriate options

  synthetic vectors
    generic vectors that do not map to hardware-supported vector types

All of the following are generic vectors that can be used on any target.

  __attribute__((vector_size(16))) signed char vsc16;
  __attribute__((vector_size(16))) unsigned short vus16;
  __attribute__((vector_size(16))) signed int vsi16;
  __attribute__((vector_size(16))) float vf16;
  __attribute__((vector_size(16))) double vd16;
  __attribute__((vector_size(16))) long long vl116;
  __attribute__((vector_size(16))) _Bool vb16;
  
  __attribute__((vector_size(8))) signed char vsc8;     *
  __attribute__((vector_size(8))) unsigned short vus8;  *
  __attribute__((vector_size(8))) signed int vsi8;      *
  __attribute__((vector_size(8))) float vf8;            *
  __attribute__((vector_size(8))) double vd8;
  __attribute__((vector_size(8))) long long vl18;
  __attribute__((vector_size(8))) _Bool vb8;
  
  __attribute__((vector_size(32))) signed char vsc32;
  __attribute__((vector_size(32))) unsigned short vus32;
  __attribute__((vector_size(32))) signed int vsi32;
  __attribute__((vector_size(32))) float vf32;
  __attribute__((vector_size(32))) double vd32;
  __attribute__((vector_size(32))) long long vl132;
  __attribute__((vector_size(32))) _Bool vb32;
  
What is the definition of "GCC vector" or "synthetic vector"?  Is that
any of these when these when compiled on powerpc*-*-linux* with
-mno-altivec, and all but the ones that map to hardware vector types
(marked with '*') when compiled with -maltivec?  The warnings about
passing synthetic vectors by reference, aren't given for 8-byte vectors,
and they are not given for 16-byte vectors that do not map to
hardware-supported vectors.

I still think that anything that isn't covered by the relevant ABI
ought to be an error, or at the very least a strong warning for every
occurrence.

Janis