Any usable SIMD implementation?

[Johannes Pfau via Digitalmars-d]

Am Thu, 7 Apr 2016 12:25:03 +1000
schrieb Manu via Digitalmars-d <digitalmars-d at puremagic.com>:

> On 6 April 2016 at 23:26, 9il via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
> > On Wednesday, 6 April 2016 at 12:40:04 UTC, Manu wrote:  
> >>
> >> On 6 April 2016 at 07:41, Johan Engelen via Digitalmars-d
> >> <digitalmars-d at puremagic.com> wrote:  
> >>>
> >>> [...]  
> >>
> >>
> >> With respect to SIMD, knowing a processor model like 'broadwell'
> >> is not helpful, since we really want to know 'sse4'. If we know
> >> processor model, then we need to keep a compile-time table in our
> >> code somewhere if every possible cpu ever known and it's
> >> associated feature set. Knowing the feature we're interested is
> >> what we need.  
> >
> >
> > Yes, however this can be implemented in a spcial Phobos module. So
> > compilers would need less work. --Ilya  
> 
> Sure, but it's an ongoing maintenance task, constantly requiring
> population with metadata for new processors that become available.
> Remember, most processors are arm processors, and there are like 20
> manufacturers of arm chips, and many of those come in a series of
> minor variations with/without sub-features present, and in a lot of
> cases, each permutation of features attached to random manufacturers
> arm chip 'X' doesn't actually have a name to describe it. It's also
> completely impractical to declare a particular arm chip by name when
> compiling for arm. It's a sloppy relationship comparing intel and AMD
> let alone the myriad of arm chips available.
> TL;DR, defining architectures with an intel-centric naming convention
> is a very bad idea.

GCC already keeps a cpu <=> feature mapping (after all it needs to know
what features it can use when you specify -mcpu) so for GDC exposing
available features isn't more difficult than exposing the CPU type.

I'm not sure if you can actually enable/disable CPU features manually
without -mcpu?

However, available features and even the type used to describe the CPU
are completely architecture specific in GCC. This means for GDC we
have to write custom code for every supported architecture. (We
already have to do this for version(Architecture) though).



FYI this is handled in the gcc/config subsystem:
https://github.com/gcc-mirror/gcc/tree/master/gcc/config

#defines for C/ARM: arm_cpu_builtins in
https://github.com/gcc-mirror/gcc/blob/master/gcc/config/arm/arm-c.c
(__ARM_NEON__ etc)

As you can see the only common requirement for backend architectures is
to call def_or_undef_macro. This means we have to modify the gcc/config
files and write replacements for arm_cpu_builtins and similar functions.

Known ARM cores and feature sets:
https://github.com/gcc-mirror/gcc/blob/master/gcc/config/arm/arm-cores.def


I guess every backend-architecture has to provide cpu names for -mcpu
so that's probably the one thing we could expose to D for all
architectures. (Names are of course GCC specific, but I guess LLVM
should use compatible names). This is less work to implement in GDC but
you'd have to duplicate the GCC feature table in phobos. OTOH
standardizing the names and available feature flag means somebody with
knowledge in that area has to write down a spec.



TLDR:
If required we can always expose compiler specific versions
(GNU_NEON/LDC_NEON) even without DMD approval/integration. This should
be coordinated with LDC though. Somebody has to make a list of needed
identifiers, preferably mentioning the matching C macros.

Things get much more complicated if you need feature flags not
currently used by / present in GCC.