On 6 June 2017 at 11:07, James Greenhalgh <james.greenha...@arm.com> 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
intrinsics.
[*] 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
approach.
