search for: inbranch

...of a function variant that is a base language identifier, or, for C++, a template-id. <simd clauses> := <simdlen>, <mask>{, <optional simd clauses>} <simdlen> := simdlen(<positive number>) | simdlen("scalable") <mask> := inbranch | notinbranch <optional simd clauses> := <linear clause> | <uniform clause> | <align clause> | {,<optional simd clauses>} <linear clause> := linear_ref(<var>,<step>) | linear_var...

...base language identifier, or, > for C++, a template-id. > > <simd clauses> := <simdlen>, <mask>{, <optional simd clauses>} > > <simdlen> := simdlen(<positive number>) | simdlen("scalable") > > <mask> := inbranch | notinbranch > > <optional simd clauses> := <linear clause> > | <uniform clause> > | <align clause> | {,<optional simd clauses>} > > <linear clause> := linear_ref(<var>,<step>) &...

...for C++, a template-id. >> > >> > <simd clauses> := <simdlen>, <mask>{, <optional simd clauses>} >> > >> > <simdlen> := simdlen(<positive number>) | simdlen("scalable") >> > >> > <mask> := inbranch | notinbranch >> > >> > <optional simd clauses> := <linear clause> >> > | <uniform clause> >> > | <align clause> | {,<optional simd clauses>} >> > >> > <linear...

...> for C++, a template-id. > > > > <simd clauses> := <simdlen>, <mask>{, <optional simd clauses>} > > > > <simdlen> := simdlen(<positive number>) | simdlen("scalable") > > > > <mask> := inbranch | notinbranch > > > > <optional simd clauses> := <linear clause> > > | <uniform clause> > > | <align clause> | {,<optional simd > > clauses>} > > > > <linear clause>...

...g a `declare variant` in a `simd` context could accept, but that wold probably raise the same problems that `declare variant` has raised. > > In fact, on AArch64, a typical use of declare variant would be more complicated than just specifying `simd` in the `context`, with `simdlen` and `[not]inbranch`. It would require also to specify the `isa` trait from the `device` set, and to use a `vendor` specific set to be able to list scalable (i.e. vector-length agnostic) functions for SVE. > > This would definitely look like implementing `declare variant`, as the attribute would need to accept...

...> for C++, a template-id. > > > > <simd clauses> := <simdlen>, <mask>{, <optional simd clauses>} > > > > <simdlen> := simdlen(<positive number>) | simdlen("scalable") > > > > <mask> := inbranch | notinbranch > > > > <optional simd clauses> := <linear clause> > > | <uniform clause> > > | <align clause> | {,<optional simd > > clauses>} > > > > <linear clause> :...

>Thank you everybody for their input, and for your patience. This is proving harder than expected! :) Thank you for doing the hard part of the work. Hideki -----Original Message----- From: Francesco Petrogalli [mailto:Francesco.Petrogalli at arm.com] Sent: Monday, June 24, 2019 11:26 AM To: Saito, Hideki <hideki.saito at intel.com> Cc: Doerfert, Johannes <jdoerfert at anl.gov>;

On Mon, 3 Jun 2019 at 20:00, Francesco Petrogalli via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Hi All, > > The original intend of this thread is to "Expose user provided vector > function for auto-vectorization.” > > I originally proposed to use OpenMP `declare variant` for the sake of > using something that is defined by a standard. The RFC itself is not

Dear all, I have just created a couple of differential reviews to enable the vectorisation of loops that have function calls to routines marked with “#pragma omp declare simd”. They can be (re)viewed here: * https://reviews.llvm.org/D27249 * https://reviews.llvm.org/D27250 The current implementation allows the loop vectorizer to generate vector code for source file as: #pragma omp declare

...; >>>>> >>>>>>>> In particular, the following declaration generates multiple >>>>>>>> vector versions, depending on the target: >>>>>>>> >>>>>>>> #pragma omp declare simd simdlen(2) notinbranch double >>>>>>>> foo(double) {…}; >>>>>>>> >>>>>>>> On x86, this generates at least 4 symbols (one for SSE, one for >>>>>>>> AVX, one for AVX2, and one for AVX512: >>>>>>>> https...