This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]