This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, AArch64] Add x86 intrinsic headers to GCC AArch64 taget
On Tue, 2017-06-20 at 17:16 -0500, Segher Boessenkool wrote:
> On Tue, Jun 20, 2017 at 09:34:25PM +0000, Joseph Myers wrote:
> > On Tue, 20 Jun 2017, Segher Boessenkool wrote:
> >
> > > > And as you see see below the gcc.target tests have to be duplicated
> > > > anyway. Even if the C code is common there will many differences in
> > > > dg-options and dg-require-effective-target. Trying to common these
> > > > implementations only creates more small files to manage.
> > >
> > > So somewhere in the near future we'll have to pull things apart again,
> > > if we go with merging things now.
> >
> > The common part in the intrinsics implementation should be exactly the
> > parts that can be implemented in GNU C without target-specific intrinsics
> > being needed. There should be nothing to pull apart if you start with the
> > right things in the common header. If a particular header has some
> > functions that can be implemented in GNU C and some that need
> > target-specific code, the generic GNU C functions should be in a common
> > header, #included by the target-specific header. The common header should
> > have no conditionals on target architectures whatever (it might have
> > conditionals on things like endianness).
>
> I don't think there is much that will end up in the common header
> eventually. If it was possible to describe most of this in plain C,
> and in such a way that it would optimise well, there would not *be*
> these intrinsics.
>
> > I don't expect many different effective-target / dg-add-options keywords
> > to be needed for common tests (obviously, duplicating tests for each
> > architecture wanting these intrinsics is generally a bad idea).
>
> Yeah, I think it should be possible to share the tests, perhaps with
> some added dg things (so that we don't have to repeat the same things
> over and over).
>
I don't see how we can share the test as this requires platform unique
dg-options and dg-require-effective-target values to enforce the
platform restrictions you mentioned earlier.