Re: [PATCH] PPC64: First in the series of patches implementing POWER8 vector math.

[Joseph Myers <joseph at codesourcery dot com>]

On Tue, 19 Feb 2019, GT wrote:

> GCC fails if an attempt is made to compile code that uses Altivec
> functionality without passing the -maltivec flag. Additionally it also
> fails on attempts to build for pre-POWER7 hardware even when
> -maltivec flag is given to the compiler. Is there need to add a
> check in configure for attempts to build libmvec on non-Altivec, non-VSX
> systems; or let the failure happen when make calls GCC?

It's best to detect the issue at configure time.  That's definitely needed 
if you want to enable libmvec by default as on x86_64.

I'm not sure why it would fail for pre-POWER7, if you pass -maltivec for 
the AltiVec versions and -mvsx for the versions requiring VSX.

> As I understand the issue here, the only vector function that can be called
> after glibc is built with this patch is the double-precision vector cosine.
> Automatic vectorization of functions is a GCC feature that is as yet
> unimplemented.

What are the effects of the pragma / attributes when using an existing GCC 
version?  Do they do nothing (code always gets built for scalar function 
calls), or do they cause compile errors or cause code to be built for an 
unsupported ABI?  That determines whether you might e.g. need 
__GNUC_PREREQ (10, 0) conditionals to avoid problems when this header gets 
used with an older GCC version not supporting the required ABI.

> Even then only the vector cosine can be tested. Unless I've missed a
> signficant point.

Yes, the expectation would be that you'd verify that, with appropriate 
options, some code using cosine and including <math.h> gets compiled to 
use the new vector cosine function, and that the calls do work as expected 
(so the compiler's ABI matches the one used by these functions).  Later 
patches in the series, adding other functions, would have such tests run 
that they properly generate calls to those functions.

We had issues for x86_64 where it turned out the vector sincos functions 
were expecting an ABI different from that (arguments being vectors of 
pointers) generated by the compiler for the pragma in the header (see 
commit ee2196bb6766ca7e63a1ba22ebb7619a3266776a that fixed this 
inconsistency).  It's to avoid such issues that it's important to verify 
things end-to-end - that sources calling each function get compiled to 
code calling the corresponding vector function and execution of that code 
behaves properly.

-- 
Joseph S. Myers
joseph@codesourcery.com