[Openmp-dev] Proposal: Resolve combined directives in parsing phase

Cownie, James H via Openmp-dev openmp-dev at lists.llvm.org
Fri Jun 9 07:44:39 PDT 2017

I think we are all in agreement.

Daniel is just pointing out that the compiler should be optimizing the case where the user implied the unneeded barrier (by writing omp parallel {omp for/do {}}), and that if it does that down the line, it’s safe for the front-end to do the omp parallel for => omp parallel { omp for {} } transformation.

-- Jim

Jim Cownie <james.h.cownie at intel.com>
SSG/DPD/TCAR (Technical Computing, Analyzers, and Runtimes)
Tel: +44 117 9071438

From: C Bergström [mailto:cbergstrom at pathscale.com]
Sent: Friday, June 9, 2017 3:39 PM
To: Daniel Schürmann <daniel.schuermann at campus.tu-berlin.de>
Cc: Cownie, James H <james.h.cownie at intel.com>; openmp-dev at lists.llvm.org
Subject: Re: [Openmp-dev] Proposal: Resolve combined directives in parsing phase

James is really clear on the point of "AS-IF" - The compiler can do anything as long as the user can't observe a difference in the behavior. The standard can say add a barrier, but if the compiler can make the code visibly act the same with our without a barrier that's all that matters.

Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20170609/2a4f5e9b/attachment.html>

More information about the Openmp-dev mailing list