On 16 February 2014 23:44, Tim Prince n...@aol.com wrote:
I don't think many people want to use both OpenMP 4 and older Intel
directives together.
I'm having less and less incentives to use anything other than omp4,
cilk and whatever. I think we should be able to map all our internal
needs to
On 2/17/2014 4:42 AM, Renato Golin wrote:
On 16 February 2014 23:44, Tim Prince n...@aol.com wrote:
I don't think many people want to use both OpenMP 4 and older Intel
directives together.
I'm having less and less incentives to use anything other than omp4,
cilk and whatever. I think we
On 17 February 2014 14:47, Tim Prince n...@aol.com wrote:
I'm continuing discussions with former Intel colleagues. If you are asking
for insight into how Intel priorities vary over time, I don't expect much,
unless the next beta compiler provides some inferences. They have talked
about
.
Robert.
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Renato
Golin
Sent: Monday, February 17, 2014 7:14 AM
To: tpri...@computer.org
Cc: gcc
Subject: Re: Vectorizer Pragmas
On 17 February 2014 14:47, Tim Prince n...@aol.com wrote:
I'm
Renato Golin wrote:
On 15 February 2014 19:26, Jakub Jelinek ja...@redhat.com wrote:
GCC supports #pragma GCC ivdep/#pragma simd/#pragma omp simd, the last one
can be used without rest of OpenMP by using -fopenmp-simd switch.
Does the simd/omp have control over the tree vectorizer? Or are
On 16 February 2014 17:23, Tobias Burnus bur...@net-b.de wrote:
As '#pragma omp simd' doesn't generate any threads and doesn't call the
OpenMP run-time library (libgomp), I would claim that it only controls the
tree vectorizer. (Hence, -fopenmp-simd was added as it permits this control
without
On 2/16/2014 2:05 PM, Renato Golin wrote:
On 16 February 2014 17:23, Tobias Burnus bur...@net-b.de wrote:
Compiler vendors (and users) have different ideas whether the SIMD pragmas
should give the compiler only a hint or completely override the compiler's
heuristics. In case of the Intel
Folks,
One of the things that we've been discussing for a while and there are
just too many options out there and none fits exactly what we're
looking for (obviously), is the vectorization control pragmas.
Our initial semantics is working on on a specific loop / lexical block to:
* turn
On Sat, Feb 15, 2014 at 06:56:42PM +, Renato Golin wrote:
1. Local pragma (#pragma vectorize), which is losing badly on the
argument that it's yet-another pragma to do mostly the same thing many
others do.
2. Using OMP SIMD pragmas (#pragma simd, #pragma omp simd) which is
already
On 15 February 2014 19:26, Jakub Jelinek ja...@redhat.com wrote:
GCC supports #pragma GCC ivdep/#pragma simd/#pragma omp simd, the last one
can be used without rest of OpenMP by using -fopenmp-simd switch.
Does the simd/omp have control over the tree vectorizer? Or are they
just flags for the
On 2/15/2014 3:36 PM, Renato Golin wrote:
On 15 February 2014 19:26, Jakub Jelinek ja...@redhat.com wrote:
GCC supports #pragma GCC ivdep/#pragma simd/#pragma omp simd, the last one
can be used without rest of OpenMP by using -fopenmp-simd switch.
Does the simd/omp have control over the tree
On 15 February 2014 22:49, Tim Prince n...@aol.com wrote:
In my experience, the (somewhat complicated) gcc --param options work
sufficiently well for specification of unrolling.
There is precedent for --param in LLVM, we could go this way, too.
Though, I can't see how it'd be applied to a
12 matches
Mail list logo
