On Mon, Oct 31, 2016 at 06:49:20PM -0500, Bill Schmidt wrote: > > > > On Oct 31, 2016, at 5:28 PM, Bill Schmidt <wschm...@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.
I suspect we may find out how many people are using #pragma GCC target and altivec vector instructions if we break their code :-( Even with attribute target instead of pragma, you need to give appropriate error messages if the user calls a built-in that the current machine doesn't support. IIRC, C++ does not support #pragma GCC target nor the target attribute. One question is how many of the billions and billions (ok, 1,345) of the rs6000 built-ins would be improved by expanding them in gimple time rather than rtl? -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
