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 vectorized mersenne twister

On 6 June 2017 at 11:07, James Greenhalgh <> wrote:

> If we don't mind that, and instead take a GCC-centric view, we could avoid
> namespace polution by using the GCC-internal names for the intrinsics
> (__builtin_aarch64_...). As those names don't form a guaranteed interface,
> that would tie us to a GCC version.
> So we have a few solutions to choose from, each of which invokes a trade-off:
>   1 Use the current names and pollute the namespace.
>   2 Use the GCC internal __builtin_aarch64* names and tie libstdc++ to GCC
>     internals.
>   3 Define a new set of namespace-clean names and complicate the Neon
>     intrinsic interface while we migrate old users to new names.
> I can see why the libstdc++ community would prefer 3) over the other options,
> but I'm reticent to take that route as the cost to our intrinsic maintainers
> and users looks high. I've added some of the other ARM port maintainers
> for their opinion.
> Are there any other options I'm missing?

If solving for C++ only is OK, then it might be feasible to do something like:

namespace __arm_neon_for_ext_random {
#include <arm_neon_internal.h>   // like arm_neon.h, but without
include guards [*]

Then the libstdc++ headers can use "using namespace
__arm_neon_for_ext_random" inside the functions which use NEON

[*] without include guards so that other header files can use the same
trick in their own namespace.

I'm not sure if this will work for all host compilers, with GCC I
think it's OK because the intrinsics are implemented as inline
functions, rather than #defines, but not all compilers have taken that

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