[LLVMdev] [Discussion] Portable SIMD programming using LLVM?

[Duncan Sands]

Hi Kevin,

> Right. LLVM supports the transformation from unsupported vector type to
> supported vector type or even scalar types.
> According to the LLVM's documentation, LLVM has two ways of doing the
> transformation, one is promoting the small vector type to larger vector type,
> the other is breaking up the large vector type into smaller ones.
> But I am wondering, how good the transformation will be in LLVM's implementation.

Nadav is looking into implementing a wider range of transforms.

> In my approach, I use strategies to capture all possible transformation. The
> transformation are not only just promoting and breaking up, but also other forms
> of transformation, like the transformation between vector types with same size.
> My goal is to make sure the simulation to be as good as possible in terms of the
> number of instructions, CPU latency, etc. If LLVM has information about the
> latency information of supported architectures, maybe I can use them to optimize
> my approach.
>
> Does LLVM have the latency information(such as CPU cycles) of SIMD instructions
> for each supported architecture?

I don't know.

Ciao, Duncan.

>
> Thanks.
>
> On Fri, Apr 1, 2011 at 2:30 AM, Duncan Sands <baldrick at free.fr
> <mailto:baldrick at free.fr>> wrote:
>
>     Hi Kevin,
>
>      > *Background*
>      > Almost modern processor families support SIMD instruction sets but the
>      > instruction set designs for each platform have different combinations of
>      > operations. The portable SIMD here is to make an uniform system of SIMD
>      > operations at all power-of-2 field widths.
>      > For example, for simd_add on SSE2, I want to have all the following
>     operations
>      > supported, simd<2^x>::add(a, b) for 2<=2^x<=register_size(register_size
>     equals
>      > 128 in SSE2). However, SSE2 only supports simd_add on field widths of 8,
>     16, 32,
>      > or 64. Hence, simulation for simd_add on field widths of 2, 4 and 128 is
>     needed.
>      > *At mean time, I want the simulation to be as good as possible*.
>
>     LLVM already does this: if you use a vector type that is not natively supported
>     then operations on it are simulated using either vector operations in another
>     vector type or scalar operations if no suitable vector type exists.
>
>     Ciao, Duncan.
>     _______________________________________________
>     LLVM Developers mailing list
>     LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu
>     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>