[LLVMdev] Implementing the ARM NEON Intrinsics for PowerPC

Stanislav Manilov stanislav.manilov at gmail.com
Wed Oct 2 04:34:24 PDT 2013


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.


> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131002/8fa7d401/attachment.html>


More information about the llvm-dev mailing list