This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, RFC, rs6000] Add overloaded built-in function support to altivec.h, and re-implement vec_add
- From: Bill Schmidt <wschmidt at linux dot vnet dot ibm dot com>
- To: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Cc: Segher Boessenkool <segher at kernel dot crashing dot org>, David Edelsohn <dje dot gcc at gmail dot com>, Will Schmidt <will_schmidt at vnet dot ibm dot com>, Michael Meissner <meissner at linux dot vnet dot ibm dot com>
- Date: Mon, 31 Oct 2016 18:49:20 -0500
- Subject: Re: [PATCH, RFC, rs6000] Add overloaded built-in function support to altivec.h, and re-implement vec_add
- Authentication-results: sourceware.org; auth=none
- References: <4fb8f7f2-ff17-6416-3869-a8576c245dde@linux.vnet.ibm.com>
>
> On Oct 31, 2016, at 5:28 PM, Bill Schmidt <wschmidt@linux.vnet.ibm.com> wrote:
>
> The other way would be to require a specific option on the command line
> to use the new dispatch mechanism. When the option is present, we would
> predefine a macro such as __PPC_FAST_VECTOR__, which would then gate the
> usage in altivec.h and overload.h. Use of #pragma GCC target to change
> the availability of Altivec, VMX, P8-vector, etc. would also be disallowed
> when the option is present. This has the advantage of always generating
> correct code, at the cost of requiring a special option before anyone
> can leverage the benefits of early vector expansion. That's unfortunate,
> but I suspect it's the best we can do.
Though I suppose we could require the option to turn off the new dispatch
mechanism, and document the change in gcc7/changes.html. A little irritating
for people already using the pragma support, but I really expect this wouldn't affect
many people at all.
-- Bill
Bill Schmidt, Ph.D.
GCC for Linux on Power
Linux on Power Toolchain
IBM Linux Technology Center
wschmidt@linux.vnet.ibm.com