llvm dev - Oct 2013 - [LLVMdev] Implementing the ARM NEON Intrinsics for PowerPC

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

On 2 October 2013 13:36, Hal Finkel <hfinkel at anl.gov> wrote:
> 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.
>
Yes, this is a good approach to understanding the problem. But I wouldn't
use this as a final solution, as it scales quadratically with the number of
supported SIMD architectures, including all variations (like NEON v7, v8
and CPU dependent choices).

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131002/93019bbd/attachment.html>

Thank you all for the help.

Here is my plan of action:

   1. Read up on NEON and AltiVec
   2. Write ((small) parts of) arm_neon.h using AltiVec intrinsics
   3. Write a function pass to convert simple (vector arithmetic) NEON C
   code to PowerPC AltiVec assembly code and submit for review.
   4. Add NEON intrinsics that map to multiple AltiVec instructions
   5. Add patterns involving surrounding instructions in order to support
   single complex AltiVec instructions
   6. (not necessarily after 4 and 5, but maybe during): Try producing C
   code with AltiVec intrinsics as output, when given C code with NEON
   intrinsics.

Things to be aware of:

   1. Endian-ness
   2. Importance of tests and documentation

I will update you once I have some progress.

Cheers,
 - Stan


On 2 October 2013 13:45, Renato Golin <renato.golin at linaro.org> wrote:
> On 2 October 2013 13:36, Hal Finkel <hfinkel at anl.gov> wrote:
>
>> 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.
>>
>
> Yes, this is a good approach to understanding the problem. But I
wouldn't
> use this as a final solution, as it scales quadratically with the number of
> supported SIMD architectures, including all variations (like NEON v7, v8
> and CPU dependent choices).
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131002/9c7aa89e/attachment.html>