llvm dev - Jan 2018 - Suggestions on code generation for SIMD

Thanks Amara very much! I will take a look!

On Mon, Jan 8, 2018 at 12:01 PM, Amara Emerson via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 8 Jan 2018, at 19:41, Linchuan Chen <chenlinc at
cse.ohio-state.edu>
> wrote:
>
> Thanks Amara so much for the info!
>
> One more question: what do people usually do if they want to generate
> vectorized code for some existing c/c++ code?
> Do they usually do C/C++ source level transformation, or do at LLVM's
IR
> level?
>
> I know clang supports auto vectorizations, such as loop vectorization and
> SLP, but they are not flexible enough if we
> want to do more custom vectorizations or handle more complex cases, for
> example, SLP might not be able to handle
> branches in the code (or may be latest version already can handle branches
> using mask).
>
> On Mon, Jan 8, 2018 at 11:30 AM, Amara Emerson via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> On 6 Jan 2018, at 00:26, Linchuan Chen via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> Hi everyone,
>>
>> I'm quite new to LLVM, but am working on a project that might need
to
>> generate some SIMD code using LLVM. The SIMD code will be using INTEL
MIC
>> intrinsics and I'm not sure about the
>> steps and tool set that I need to use to generate those.
>>
>> I also have a confusion on the following problems:
>>
>>    1. Do people usually generate SIMD code at source code level, using
>>    __m512?
>>    2. If not, does LLVM have corresponding IR instructions for the SIMD
>>    registers and instructions?
>>
>>
>> Since I'm new, I would appreciate any help that could give me some
>> directions at any level. Some references would also help. Thanks in
advance!
>>
>>
>>
>> Hi Linchuan,
>>
>> I believe clang supports Intel AVX512 intrinsics so it should be
possible
>> to generate vector code using that.
>>
>> For 2), LLVM has first class vector types such as <4 x i32> and
can do
>> the usual things on those types, including masking. The vectoriser is
where
>> most of the vector code that LLVM generates will originate from. These
>> types aren’t target specific however, and there are no notions of
vector
>> “registers” at the IR level.
>>
>> Cheers,
>> Amara
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>
> The vast majority of the time people will rely on source level pragmas
> [1], LLVM IR is designed to be machine friendly, not something intended for
> users to manually edit themselves. You can do it, but it’s tedious and
> error prone. If you need more control over the vectorisation than the
> pragmas allow, then the C intrinsics are the best choice.
>
> Amara
>
> [1] http://clang.llvm.org/docs/LanguageExtensions.html#
> extensions-for-loop-hint-optimizations
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>

-- 
Sincerely,
Linchuan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180108/9a29eabe/attachment.html>

>     The vast majority of the time people will rely on source level pragmas
[1],
>     LLVM IR is designed to be machine friendly, not something intended for
>     users to manually edit themselves. You can do it, but it’s tedious and
>     error prone. If you need more control over the vectorisation than the
>     pragmas allow, then the C intrinsics are the best choice.
> 
>     Amara
> 
>     [1] http://clang.llvm.org/docs/LanguageExtensions.html#
>     extensions-for-loop-hint-optimizations
A large portion of user still use intrinsics too, as provided in
avxintrin.h and the likes. They are then lowered to a single/few
llvm instructions with vector operands.

Thanks Serge! This means for every new intrinsic set, a systematic change
should be made to LLVM to support the new intrinsic set, right? The change
should include frontend change, IR instruction set change, as well as low
level code generation changes?

On Tue, Jan 9, 2018 at 12:39 AM, serge guelton via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> >     The vast majority of the time people will rely on source level
> pragmas [1],
> >     LLVM IR is designed to be machine friendly, not something intended
> for
> >     users to manually edit themselves. You can do it, but it’s tedious
> and
> >     error prone. If you need more control over the vectorisation than
the
> >     pragmas allow, then the C intrinsics are the best choice.
> >
> >     Amara
> >
> >     [1] http://clang.llvm.org/docs/LanguageExtensions.html#
> >     extensions-for-loop-hint-optimizations
>
> A large portion of user still use intrinsics too, as provided in
> avxintrin.h and the likes. They are then lowered to a single/few
> llvm instructions with vector operands.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>


-- 
Sincerely,
Linchuan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180109/edf3f1d6/attachment.html>