[LLVMdev] Implementing the ARM NEON Intrinsics for PowerPC

Hal Finkel hfinkel at anl.gov
Wed Oct 2 05:36:47 PDT 2013


----- Original Message -----
> On 2 October 2013 12:17, Renato Golin < renato.golin at linaro.org >
> wrote:
> 
> 
> 
> 
> On 2 October 2013 10:12, Steven Newbury < steve at snewbury.org.uk >
> wrote:
> 
> 
> 
> 
> 
> How does this make any sense?
> 
> 
> I have to agree with you that this doesn't make much sense, but there
> is a case where you would want something like that: when the
> original source uses NEON intrinsics, and there is no alternative in
> AltiVec, AVX or even plain C.
> 
> 
> This is exactly the case that I am in. I want to make DSP code
> written in C, but with NEON intrinsics "portable" as it is less
> feasible to rewrite it.

Are you using Clang as the frontend? If so, my recommendation would be to start by creating a header file that implements the NEON intrinsics in terms of generic functionality and the Altivec ones. The header file would need to look kind of like this:

#if defined(__powerpc__) || defined(__ppc__)

#define neon_intrinsic1 ppc_neon_intrinsic1
static __inline__ vec_type __attribute__((__always_inline__, __nodebug__))
ppc_neon_intrinsic1(vec_type a1, vec_type a2) {
  ...
}

...

#endif

If you look in tools/clang/lib/Headers you'll see lots of example intrinsics header files, and if you look in your build directory in tools/clang/lib/Headers you'll find the arm_neon.h.inc file.

You can certainly do this in terms of an LLVM transformation, but I think that creating some kind of header file would be, at least, where I'd start prototyping this.

Also, you'll want to make sure that the endianness of the ARM and PPC environments agree (or that the code is endian-neutral), otherwise you'll likely have bigger problems ;)

 -Hal

> 
> 
> 
> 
> Stanislav,
> 
> 
> If I got it right above, I think it would be better if you could do
> that transformation in IR, with a mapping infrastructure between
> each SIMD ISA. Something that could represent every possible SIMD
> instruction, and how each target represents them, so in one side you
> read the intrinsics (and possibly IR operations on vectors),
> translate to this meta-SIMD language, then export on the SIMD
> language that you want.
> 
> 
> A tool like this, possibly exporting back to C code (so you can add
> it to your project as an one-off pass), would be valuable to all
> programs that have legacy hard-coded SSE routines to run on any
> platform that support SIMD operations.
> 
> 
> I have no idea how easy would be to do that, let alone if it's at all
> possible, but it seems that this is what you want. Correct me if I'm
> wrong.
> 
> 
> Again, the tool you describe is exactly what I ultimately want to
> create. The translation to AltiVec would be a step towards
> understanding how to manipulate the intrinsics, but it is not a goal
> on its own.
> 
> 
> 
> Do you have any ideas where in the whole LLVM structure would it fit
> (should it be implemented as a separate optional pass)?
> 
> 
> Thanks,
> - Stan
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory



More information about the llvm-dev mailing list