llvm dev - Aug 2019 - [LLVM] (RFC) Addition/Support of new Vectorization Pragmas in LLVM

Hello all,

We are students from Indian Institute of Technology(IIT), Hyderabad, we
would like to propose the addition of the following pragmas in LLVM that
aide in (or possibly increase the scope of) vectorization in LLVM (in
comparison with other compilers).



   1.

   ivdep
   2.

   Nontemporal
   3.

   [no]vecremainder
   4.

   [no]mask_readwrite
   5.

   [un]aligned


Could you please check the following Google document for the semantic
description of these pragmas:

https://docs.google.com/document/d/1YjGnyzWFKJvqbpCsZicCUczzU8HlLHkmG9MssUw-R1A/edit?usp=sharing

It would be great if you could please review the above document and suggest
us on how to proceed further (either about the semantics, or, about the
code sections in LLVM).

Thank you

Yashas, Happy, Sai Praharsh, and Bhavya

B.Tech 3rd year, IITH.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190808/a3ef428f/attachment.html>

Hi,


First, as a high-level note, you posted a link to a Google doc, and at the end
of the Google doc, you have a list of questions that you'd like answered. In
the future, please put the questions directly in the email. For one thing, more
people will read your email than will open your Google doc. Second, having the
questions in the email should allow a better threading structure to the replies.


  *   Ivdep: Is clang loop vectorize(assume_safety) equivalent to ivdep? To what
extent do the semantics of ivdep need to be modified for Clang to create an
equally “useful pragma”? To what extent would it be helpful to have this pragma
in Clang?

  *   Nontemporal:What kind of analysis can we do in LLVM to find where to use
nontemporal accesses? Any help would be greatly appreciated.

  *   vecremainder/novecremainder: Should the pragma simply call the vectorizer
to attempt to vectorize the remainder loop, or should the vectorizer use a
different method?

  *   mask_readwrite/nomask_readwrite: Is it a good idea to implement a pragma
that will generate mask intrinsics in the IR? What other architectures (except
x86) has support for masked read/writes?


Reference:https://llvm.org/devmtg/2015-04/slides/MaskedIntrinsics.pdf


LLVM has mask intrinsics for targets with AVX, AVX2, AVX-512.
>From Slides: ”Most of the targets do not support masked instructions,
optimization of instructions with masks is problematic, avoid introducing new
masked instructions into LLVM IR”
  *   aligned/unaligned: Is it worthwhile to have LLVM specific pragma rather
depending on OpenMP?


 -Hal


Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory


________________________________
From: llvm-dev <llvm-dev-bounces at
lists.llvm.org><mailto:llvm-dev-bounces at lists.llvm.org> on behalf of
HAPPY Mahto via llvm-dev <llvm-dev at lists.llvm.org><mailto:llvm-dev
at lists.llvm.org>
Sent: Thursday, August 8, 2019 11:55 AM
To: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
<llvm-dev at lists.llvm.org><mailto:llvm-dev at lists.llvm.org>
Cc: BHAVYA BAGLA <cs17btech11007 at iith.ac.in><mailto:cs17btech11007
at iith.ac.in>; MAMIDALA SAI PRAHARSH <es17btech11013 at
iith.ac.in><mailto:es17btech11013 at iith.ac.in>; HAPPY KUMAR
<cs17btech11018 at iith.ac.in><mailto:cs17btech11018 at iith.ac.in>;
YASHAS ANDALURI <es17btech11025 at iith.ac.in><mailto:es17btech11025 at
iith.ac.in>
Subject: [llvm-dev] [LLVM] (RFC) Addition/Support of new Vectorization Pragmas
in LLVM

Hello all,

We are students from Indian Institute of Technology(IIT), Hyderabad, we would
like to propose the addition of the following pragmas in LLVM that aide in (or
possibly increase the scope of) vectorization in LLVM (in comparison with other
compilers).

  1.  ivdep

  2.  Nontemporal

  3.  [no]vecremainder

  4.  [no]mask_readwrite

  5.  [un]aligned


Could you please check the following Google document for the semantic
description of these pragmas:

https://docs.google.com/document/d/1YjGnyzWFKJvqbpCsZicCUczzU8HlLHkmG9MssUw-R1A/edit?usp=sharing

[https://lh4.googleusercontent.com/BFUxChQk941g1yFLPCtFJ6l0ADX-mYOx9H4rwnKhKhax-5qlknMQuqS5g1glN-44f0Ls3w=w1200-h630-p]<https://docs.google.com/document/d/1YjGnyzWFKJvqbpCsZicCUczzU8HlLHkmG9MssUw-R1A/edit?usp=sharing>
Vectorization Pragmas LLVM:RFC:
V2<https://docs.google.com/document/d/1YjGnyzWFKJvqbpCsZicCUczzU8HlLHkmG9MssUw-R1A/edit?usp=sharing>
docs.google.com
Vectorization Pragmas in LLVM: An RFC Yashas Andaluri, Happy Mahto, M Sai
Praharsh, Bhavya Bagla IIT Hyderabad Aug 8th, 2019 [Thanks to feedback from
Venugopal Raghavan, Shivarama Rao (AMD) and Michael Kruse & Hal Finkel
(ANL).] Vectorization Pragmas ivdep vector(nontemporal) vector([no]vecrema...



It would be great if you could please review the above document and suggest us
on how to proceed further (either about the semantics, or, about the code
sections in LLVM).


Thank you

Yashas, Happy, Sai Praharsh, and Bhavya

B.Tech 3rd year, IITH.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190808/06ecce32/attachment.html>

On 8/8/19 2:03 PM, Hal Finkel wrote:

Hi,


First, as a high-level note, you posted a link to a Google doc, and at the end
of the Google doc, you have a list of questions that you'd like answered. In
the future, please put the questions directly in the email. For one thing, more
people will read your email than will open your Google doc. Second, having the
questions in the email should allow a better threading structure to the replies.


  *   Ivdep: Is clang loop vectorize(assume_safety) equivalent to ivdep? To what
extent do the semantics of ivdep need to be modified for Clang to create an
equally “useful pragma”? To what extent would it be helpful to have this pragma
in Clang?



There is a fundamental problem with the way that ivdep is defined by Intel's
current documentation, at least for C/C++. As you note in your Google doc, it
essentially says that the optimizer may ignore loop-carried dependencies except
for those dependencies it can definitely prove are present. These are not
semantics that any other compiler can actually replicate, and is not equivalent
to "vectorize(assume_safety)" (which asserts that no loop-carried
dependencies are present). The good news is that, in conversations I've had
with Intel, an openness to making these semantics more concrete has been
expressed. I think it would be very useful to have ivdep in Clang, but only
after we nail down the semantics with Intel is some useful way.


  *
  *   Nontemporal:What kind of analysis can we do in LLVM to find where to use
nontemporal accesses? Any help would be greatly appreciated.



If you're asking about the pragma, then what analysis is necessary? In
general, you're looking for accesses that won't benefit from caching
(e.g., streaming data which is not accessed again).


  *
  *   vecremainder/novecremainder: Should the pragma simply call the vectorizer
to attempt to vectorize the remainder loop, or should the vectorizer use a
different method?



Something like that. There were patches posted at some point to enable tail-loop
vectorization. At this point, I imagine that you'd construct a VPlan with
the vectorized tail.


  *
  *   mask_readwrite/nomask_readwrite: Is it a good idea to implement a pragma
that will generate mask intrinsics in the IR? What other architectures (except
x86) has support for masked read/writes?


ARM SVE might also fall into this category.


  *


Reference:https://llvm.org/devmtg/2015-04/slides/MaskedIntrinsics.pdf


LLVM has mask intrinsics for targets with AVX, AVX2, AVX-512.
>From Slides: ”Most of the targets do not support masked instructions,
optimization of instructions with masks is problematic, avoid introducing new
masked instructions into LLVM IR”
  *   aligned/unaligned: Is it worthwhile to have LLVM specific pragma rather
depending on OpenMP?


My opinion is that, so long as we have our own vectorization pragma, it should
be as fully-featured as people request it to be.


 -Hal



  *


 -Hal


Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory


________________________________
From: llvm-dev <llvm-dev-bounces at
lists.llvm.org><mailto:llvm-dev-bounces at lists.llvm.org> on behalf of
HAPPY Mahto via llvm-dev <llvm-dev at lists.llvm.org><mailto:llvm-dev
at lists.llvm.org>
Sent: Thursday, August 8, 2019 11:55 AM
To: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
<llvm-dev at lists.llvm.org><mailto:llvm-dev at lists.llvm.org>
Cc: BHAVYA BAGLA <cs17btech11007 at iith.ac.in><mailto:cs17btech11007
at iith.ac.in>; MAMIDALA SAI PRAHARSH <es17btech11013 at
iith.ac.in><mailto:es17btech11013 at iith.ac.in>; HAPPY KUMAR
<cs17btech11018 at iith.ac.in><mailto:cs17btech11018 at iith.ac.in>;
YASHAS ANDALURI <es17btech11025 at iith.ac.in><mailto:es17btech11025 at
iith.ac.in>
Subject: [llvm-dev] [LLVM] (RFC) Addition/Support of new Vectorization Pragmas
in LLVM

Hello all,

We are students from Indian Institute of Technology(IIT), Hyderabad, we would
like to propose the addition of the following pragmas in LLVM that aide in (or
possibly increase the scope of) vectorization in LLVM (in comparison with other
compilers).

  1.  ivdep

  2.  Nontemporal

  3.  [no]vecremainder

  4.  [no]mask_readwrite

  5.  [un]aligned


Could you please check the following Google document for the semantic
description of these pragmas:

https://docs.google.com/document/d/1YjGnyzWFKJvqbpCsZicCUczzU8HlLHkmG9MssUw-R1A/edit?usp=sharing

[https://lh4.googleusercontent.com/BFUxChQk941g1yFLPCtFJ6l0ADX-mYOx9H4rwnKhKhax-5qlknMQuqS5g1glN-44f0Ls3w=w1200-h630-p]<https://docs.google.com/document/d/1YjGnyzWFKJvqbpCsZicCUczzU8HlLHkmG9MssUw-R1A/edit?usp=sharing>
Vectorization Pragmas LLVM:RFC:
V2<https://docs.google.com/document/d/1YjGnyzWFKJvqbpCsZicCUczzU8HlLHkmG9MssUw-R1A/edit?usp=sharing>
docs.google.com
Vectorization Pragmas in LLVM: An RFC Yashas Andaluri, Happy Mahto, M Sai
Praharsh, Bhavya Bagla IIT Hyderabad Aug 8th, 2019 [Thanks to feedback from
Venugopal Raghavan, Shivarama Rao (AMD) and Michael Kruse & Hal Finkel
(ANL).] Vectorization Pragmas ivdep vector(nontemporal) vector([no]vecrema...



It would be great if you could please review the above document and suggest us
on how to proceed further (either about the semantics, or, about the code
sections in LLVM).


Thank you

Yashas, Happy, Sai Praharsh, and Bhavya

B.Tech 3rd year, IITH.

--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190808/df2bdf89/attachment.html>

HAPPY Mahto via llvm-dev <llvm-dev at lists.llvm.org> writes:
> 2 Nontemporal
Is this a hint or a command?  If it's a command then this would
implicitly specify the data is aligned on some targets (e.g. Intel X86).
I'm not sure we want to make that implicit assumption as it is very easy
for the programmer to get this wrong.

                      -David

On Fri, Aug 9, 2019 at 11:51 AM David Greene via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> HAPPY Mahto via llvm-dev <llvm-dev at lists.llvm.org> writes:
>
> > 2 Nontemporal
>
> Is this a hint or a command?  If it's a command then this would
> implicitly specify the data is aligned on some targets (e.g. Intel X86).
> I'm not sure we want to make that implicit assumption as it is very
easy
> for the programmer to get this wrong.
>
I think it has to be a hint.  If it is a command, what is it's meaning on
non-x86 processors where write-through and write-back are controlled in
different ways (or are just uncontrollable)?

For example, some PPC set cache write back/through at the page level (
https://www.nxp.com/docs/en/data-sheet/MPC603.pdf).  Would the command
implementation have to try to set the page properties to do as the user
directed?

There are also cases where the compiler may know that the user is often
wrong about the utility of non-temporal memory access and ignoring it is an
effective optimization.  This is potentially relevant to profile-guided
optimization.

Jeff

-- 
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190809/f5271b6a/attachment.html>