Re: [PATCH] D11738: Add new llvm.loop.unroll.enable metadata which is now generated by "#pragma unroll" directive

[Tyler Nowicki]

tyler.nowicki added a subscriber: tyler.nowicki.
tyler.nowicki added a comment.

Hi Mark,

The patch LGTM!

Tyler


http://reviews.llvm.org/D11738



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [Patch][LoopVectorize]Late evaluation of vectorization requirements

[Tyler Nowicki]

Hi,

Could I get a review of these patches?

Thanks,

Tyler


> On Jul 27, 2015, at 4:45 PM, Tyler Nowicki  wrote:
> 
> Please ignore the debug line in the LLVM late-evaluation patch. It won’t be 
> part of the commit.
> 
> +  DEBUG(dbgs() << "LV: Emitting analysis message.\n”);
> 
> Tyler
> 
>> On Jul 27, 2015, at 3:23 PM, Tyler Nowicki > <mailto:tnowi...@apple.com>> wrote:
>> 
>> Hi Hal,
>> 
>> Thanks for the review! No worries about the delay.
>> 
>>>> Could I get a review of these patches for cfe and llvm?
>>> 
>>> Hi Tyler,
>>> 
>>> I'm apologize for the delay. I think this generally looks good, but I don't 
>>> understand the motivation for introducing the additional FrontendOptions 
>>> member. Why not just make a subclass of 
>>> DiagnosticInfoOptimizationRemarkAnalysis that the frontend can handle 
>>> specially (and detect using the normal isa/dyn_cast mechanism?\
>> 
>> The diagnostic handling code doesn’t use isa or dyn_cast, rather it uses 
>> switches to select between different types. I modified the patch to use a 
>> subclass rather than a member variable. Let me know what patch you think 
>> would work out better?
>> 
>> 
>>>> I should have also said in my previous email that I am not thrilled
>>>> by the need to use O3 in the clang-side test.
>>> 
>>> So using -O2 or using -fvectorize does not help?
>> 
>> Using -O1 with -fvectorize seems to work, at least it is a smaller set of 
>> passes than O3.
>> 
>> I attached the updated patches. I also noticed that 
>> DiagnosticInfoOptimizationBase::classof() was incorrectly implemented. It 
>> would need its own diagnostic kind, but that doesn’t make sense because you 
>> would never instantiate the base class. I thought it was best just to remove 
>> it. See the third patch.
>> 
>> Tyler
>> 
>> 
>> 
>> 
> 
> ___
> cfe-commits mailing list
> cfe-comm...@cs.uiuc.edu <mailto:cfe-comm...@cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits 
> <http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D48808: [CodeGen] Emit parallel_loop_access for each loop in the loop stack.

[Tyler Nowicki via cfe-commits]

Hi Michael, Hal,

Sorry it has been a while since I looked at this. My memory is a little
fuzzy. The intent of 'assume_safety' is to tell LAA to skip dependency
checking on loads and stores so the vectorizer doesn't stop as soon as it
sees both in a loop. At the time 'assume_safety' was implemented the
vectorizer was limited to inner-loops. I am not up-to-date but it seems to
have the ability to perform some vectorization of non-inner loop
instructions?

If we can vectorize non-inner loop instructions then what behavior would
make the most sense: 'assume_safety' applies to the same loop scope(s) as
the other loop pragmas, or it applies to all nested loops?

My opinion is that for consistency 'assume_safety' and similar options
apply to the same scope(s) as 'vectorize(enable)'. But I am open to
alternatives if others see it differently.

Tyler Nowicki

On Mon, Jul 2, 2018 at 10:44 AM Michael Kruse via Phabricator <
revi...@reviews.llvm.org> wrote:

> Meinersbur added a comment.
>
> In https://reviews.llvm.org/D48808#1149534, @ABataev wrote:
>
> > I don't think that this is the intended behavior of the `#pragma clang
> loop`. it is better to ask the author of this pragma is this correct or not.
>
>
> I understand it as the intended behavior of the `assume_safety` option
> (also used for `#pragma omp simd`).
>
> @tyler.nowicki What is the intended behaviour?
>
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D48808
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D69088: [Lex] #pragma clang transform

[Tyler Nowicki via cfe-commits]

Sorry if this is answered in the patches but what happens if a loop has
both #pragma clang loop and transform defined before it? I guess it
probably shouldn't work.

Perhaps instead you could create a new option to indicate that the order
should be respected.

#pragma clang loop respect_order  <- optionally with (true) or (false)

That approach would avoid the inevitable conflicts of having both loop and
transform pragmas on the same loop.


On Thu, Oct 17, 2019 at 5:27 PM Michael Kruse via Phabricator <
revi...@reviews.llvm.org> wrote:

> Meinersbur added a comment.
>
> In D69088#1713623 , @hsaito
> wrote:
>
> > @Meinersbur, if I remember correctly, there was an RFC discussion on
> this topic, right? If yes, would you post the pointer to that? I need a
> refresher on what has been discussed/settled in the past.
>
>
> https://lists.llvm.org/pipermail/cfe-dev/2018-May/058141.html
>
>
> Repository:
>   rC Clang
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D69088/new/
>
> https://reviews.llvm.org/D69088
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [Patch][LoopVectorize]Late evaluation of vectorization requirements

[Tyler Nowicki via cfe-commits]

Thanks!

Committed in clang r244492, llvm r244489/r244505/r244494.

Tyler

> On Aug 9, 2015, at 9:33 PM, Hal Finkel  wrote:
> 
> Hi Tyler,
> 
> These LGTM, thanks!
> 
> -Hal
> 
> - Original Message -----
>> From: "Tyler Nowicki" 
>> To: "Hal J. Finkel" , "Gerolf Hoflehner" 
>> 
>> Cc: "Commit Messages and Patches for LLVM" , 
>> "llvm cfe" 
>> Sent: Thursday, August 6, 2015 3:12:29 PM
>> Subject: Re: [Patch][LoopVectorize]Late evaluation of vectorization  
>> requirements
>> 
>> 
>> I’ve updated the patches a bit. I am going post another pair of
>> patches to add another late diagnostic soon as well.
>> 
>> 
>> Please review,
>> 
>> 
>> Tyler
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Aug 5, 2015, at 1:57 PM, Tyler Nowicki < tnowi...@apple.com >
>> wrote:
>> 
>> 
>> Hi,
>> 
>> 
>> Could I get a review of these patches?
>> 
>> 
>> Thanks,
>> 
>> 
>> Tyler
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Jul 27, 2015, at 4:45 PM, Tyler Nowicki < tnowi...@apple.com >
>> wrote:
>> 
>> Please ignore the debug line in the LLVM late-evaluation patch. It
>> won’t be part of the commit.
>> 
>> 
>> + DEBUG(dbgs() << "LV: Emitting analysis message.\n”);
>> 
>> 
>> Tyler
>> 
>> 
>> 
>> 
>> 
>> On Jul 27, 2015, at 3:23 PM, Tyler Nowicki < tnowi...@apple.com >
>> wrote:
>> 
>> 
>> 
>> Hi Hal,
>> 
>> 
>> Thanks for the review! No worries about the delay.
>> 
>> 
>> 
>> 
>> 
>> 
>> Could I get a review of these patches for cfe and llvm?
>> 
>> Hi Tyler,
>> 
>> I'm apologize for the delay. I think this generally looks good, but I
>> don't understand the motivation for introducing the additional
>> FrontendOptions member. Why not just make a subclass of
>> DiagnosticInfoOptimizationRemarkAnalysis that the frontend can
>> handle specially (and detect using the normal isa/dyn_cast
>> mechanism?\
>> 
>> 
>> 
>> The diagnostic handling code doesn’t use isa or dyn_cast, rather it
>> uses switches to select between different types. I modified the
>> patch to use a subclass rather than a member variable. Let me know
>> what patch you think would work out better?
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> I should have also said in my previous email that I am not thrilled
>> by the need to use O3 in the clang-side test.
>> 
>> So using -O2 or using -fvectorize does not help?
>> 
>> 
>> 
>> Using -O1 with -fvectorize seems to work, at least it is a smaller
>> set of passes than O3.
>> 
>> 
>> I attached the updated patches. I also noticed that
>> DiagnosticInfoOptimizationBase::classof() was incorrectly
>> implemented. It would need its own diagnostic kind, but that doesn’t
>> make sense because you would never instantiate the base class. I
>> thought it was best just to remove it. See the third patch.
>> 
>> 
>> Tyler
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> cfe-commits mailing list
>> cfe-comm...@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>> 
>> 
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r244506 - Remove non-ascii characters.

[Tyler Nowicki via cfe-commits]

Author: tnowicki
Date: Mon Aug 10 16:18:01 2015
New Revision: 244506

URL: http://llvm.org/viewvc/llvm-project?rev=244506&view=rev
Log:
Remove non-ascii characters.

Modified:
cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
cfe/trunk/test/Frontend/optimization-remark-options.c

Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=244506&r1=244505&r2=244506&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Mon Aug 10 
16:18:01 2015
@@ -46,8 +46,8 @@ def remark_fe_backend_optimization_remar
 def remark_fe_backend_optimization_remark_analysis : Remark<"%0">, BackendInfo,
 InGroup;
 def remark_fe_backend_optimization_remark_analysis_fpcommute : Remark<"%0; "
-"allow commutativity by specifying ‘#pragma clang loop 
vectorize(enable)’ "
-"before the loop or by providing the compiler option ‘-ffast-math’">,
+"allow commutativity by specifying '#pragma clang loop vectorize(enable)' "
+"before the loop or by providing the compiler option '-ffast-math'">,
 BackendInfo, InGroup;
 def warn_fe_backend_optimization_failure : Warning<"%0">, BackendInfo,
 InGroup, DefaultWarn;

Modified: cfe/trunk/test/Frontend/optimization-remark-options.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/optimization-remark-options.c?rev=244506&r1=244505&r2=244506&view=diff
==
--- cfe/trunk/test/Frontend/optimization-remark-options.c (original)
+++ cfe/trunk/test/Frontend/optimization-remark-options.c Mon Aug 10 16:18:01 
2015
@@ -1,6 +1,6 @@
 // RUN: %clang -O1 -fvectorize -Rpass-analysis=loop-vectorize -emit-llvm -S %s 
-o - 2>&1 | FileCheck %s
 
-// CHECK: {{.*}}:9:11: remark: loop not vectorized: vectorization requires 
changes in the order of operations, however IEEE 754 floating-point operations 
are not commutative; allow commutativity by specifying ‘#pragma clang loop 
vectorize(enable)’ before the loop or by providing the compiler option 
‘-ffast-math’
+// CHECK: {{.*}}:9:11: remark: loop not vectorized: vectorization requires 
changes in the order of operations, however IEEE 754 floating-point operations 
are not commutative; allow commutativity by specifying '#pragma clang loop 
vectorize(enable)' before the loop or by providing the compiler option 
'-ffast-math'
 
 double foo(int N) {
   double v = 0.0;


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r244492 - Append options for floating-point commutivity when related diagnostics are produced.

[Tyler Nowicki via cfe-commits]

Thanks Aaron!

Fixed in r244506.

Tyler

On Mon, Aug 10, 2015 at 12:58 PM, Aaron Ballman 
wrote:

> On Mon, Aug 10, 2015 at 3:56 PM, Tyler Nowicki via cfe-commits
>  wrote:
> > Author: tnowicki
> > Date: Mon Aug 10 14:56:40 2015
> > New Revision: 244492
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=244492&view=rev
> > Log:
> > Append options for floating-point commutivity when related diagnostics
> are produced.
> >
> > With this patch clang appends the command line options that would allow
> vectorization when floating-point commutativity is required. Specifically
> those are enabling fast-math or specifying a loop hint.
> >
> > Added:
> > cfe/trunk/test/Frontend/optimization-remark-options.c
> > Modified:
> > cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> > cfe/trunk/lib/CodeGen/CodeGenAction.cpp
> >
> > Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=244492&r1=244491&r2=244492&view=diff
> >
> ==
> > --- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
> > +++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Mon Aug 10
> 14:56:40 2015
> > @@ -45,6 +45,10 @@ def remark_fe_backend_optimization_remar
> >  InGroup;
> >  def remark_fe_backend_optimization_remark_analysis : Remark<"%0">,
> BackendInfo,
> >  InGroup;
> > +def remark_fe_backend_optimization_remark_analysis_fpcommute :
> Remark<"%0; "
> > +"allow commutativity by specifying ‘#pragma clang loop
> vectorize(enable)’ "
> > +"before the loop or by providing the compiler option
> ‘-ffast-math’">,
> > +BackendInfo, InGroup;
>
> It looks like some non-ASCII characters snuck in here.
>
> >  def warn_fe_backend_optimization_failure : Warning<"%0">, BackendInfo,
> >  InGroup, DefaultWarn;
> >  def note_fe_backend_optimization_remark_invalid_loc : Note<"could "
> >
> > Modified: cfe/trunk/lib/CodeGen/CodeGenAction.cpp
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenAction.cpp?rev=244492&r1=244491&r2=244492&view=diff
> >
> ==
> > --- cfe/trunk/lib/CodeGen/CodeGenAction.cpp (original)
> > +++ cfe/trunk/lib/CodeGen/CodeGenAction.cpp Mon Aug 10 14:56:40 2015
> > @@ -256,6 +256,8 @@ namespace clang {
> >  const llvm::DiagnosticInfoOptimizationRemarkMissed &D);
> >  void OptimizationRemarkHandler(
> >  const llvm::DiagnosticInfoOptimizationRemarkAnalysis &D);
> > +void OptimizationRemarkHandler(
> > +const llvm::DiagnosticInfoOptimizationRemarkAnalysisFPCommute
> &D);
> >  void OptimizationFailureHandler(
> >  const llvm::DiagnosticInfoOptimizationFailure &D);
> >};
> > @@ -500,6 +502,17 @@ void BackendConsumer::OptimizationRemark
> >  D, diag::remark_fe_backend_optimization_remark_analysis);
> >  }
> >
> > +void BackendConsumer::OptimizationRemarkHandler(
> > +const llvm::DiagnosticInfoOptimizationRemarkAnalysisFPCommute &D) {
> > +  // Optimization analysis remarks are active only if the
> -Rpass-analysis
> > +  // flag has a regular expression that matches the name of the pass
> > +  // name in \p D.
> > +  if (CodeGenOpts.OptimizationRemarkAnalysisPattern &&
> > +
> CodeGenOpts.OptimizationRemarkAnalysisPattern->match(D.getPassName()))
> > +EmitOptimizationMessage(
> > +D,
> diag::remark_fe_backend_optimization_remark_analysis_fpcommute);
> > +}
> > +
> >  void BackendConsumer::OptimizationFailureHandler(
> >  const llvm::DiagnosticInfoOptimizationFailure &D) {
> >EmitOptimizationMessage(D,
> diag::warn_fe_backend_optimization_failure);
> > @@ -553,6 +566,12 @@ void BackendConsumer::DiagnosticHandlerI
> >  OptimizationRemarkHandler(
> >  cast(DI));
> >  return;
> > +  case llvm::DK_OptimizationRemarkAnalysisFPCommute:
> > +// Optimization remarks are always handled completely by this
> > +// handler. There is no generic way of emitting them.
> > +OptimizationRemarkHandler(
> > +cast(DI));
> > +return;
> >case llvm::DK_OptimizationFailure:
> >  // Optimization failures are always hand

r244517 - Make frontend floating-point commutivity test X86 specific to avoid cost-model related problems on arm-thumb and hexagon.

[Tyler Nowicki via cfe-commits]

Author: tnowicki
Date: Mon Aug 10 17:17:40 2015
New Revision: 244517

URL: http://llvm.org/viewvc/llvm-project?rev=244517&view=rev
Log:
Make frontend floating-point commutivity test X86 specific to avoid cost-model 
related problems on arm-thumb and hexagon.

Modified:
cfe/trunk/test/Frontend/optimization-remark-options.c

Modified: cfe/trunk/test/Frontend/optimization-remark-options.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/optimization-remark-options.c?rev=244517&r1=244516&r2=244517&view=diff
==
--- cfe/trunk/test/Frontend/optimization-remark-options.c (original)
+++ cfe/trunk/test/Frontend/optimization-remark-options.c Mon Aug 10 17:17:40 
2015
@@ -1,4 +1,4 @@
-// RUN: %clang -O1 -fvectorize -Rpass-analysis=loop-vectorize -emit-llvm -S %s 
-o - 2>&1 | FileCheck %s
+// RUN: %clang -O1 -fvectorize -target x86_64-unknown-unknown 
-Rpass-analysis=loop-vectorize -emit-llvm -S %s -o - 2>&1 | FileCheck %s
 
 // CHECK: {{.*}}:9:11: remark: loop not vectorized: vectorization requires 
changes in the order of operations, however IEEE 754 floating-point operations 
are not commutative; allow commutativity by specifying '#pragma clang loop 
vectorize(enable)' before the loop or by providing the compiler option 
'-ffast-math'
 


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r244526 - Append options for vectorization when pointer checking threshold is exceeded.

[Tyler Nowicki via cfe-commits]

Author: tnowicki
Date: Mon Aug 10 18:05:16 2015
New Revision: 244526

URL: http://llvm.org/viewvc/llvm-project?rev=244526&view=rev
Log:
Append options for vectorization when pointer checking threshold is exceeded.

Following one of the appended options will allow the loop to be vectorized. We 
do not include a command line option for modifying the pointer checking 
threshold because there is no clang-level interface for this currently.

Modified:
cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
cfe/trunk/lib/CodeGen/CodeGenAction.cpp
cfe/trunk/test/Frontend/optimization-remark-options.c

Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=244526&r1=244525&r2=244526&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Mon Aug 10 
18:05:16 2015
@@ -49,6 +49,12 @@ def remark_fe_backend_optimization_remar
 "allow commutativity by specifying '#pragma clang loop vectorize(enable)' "
 "before the loop or by providing the compiler option '-ffast-math'">,
 BackendInfo, InGroup;
+def remark_fe_backend_optimization_remark_analysis_aliasing : Remark<"%0; "
+"avoid runtime pointer checking when you know the arrays will always be "
+"independent by specifying '#pragma clang loop vectorize(assume_safety)' "
+"before the loop or by specifying 'restrict' on the array arguments. "
+"Erroneous results will occur if these options are incorrectly applied!">,
+BackendInfo, InGroup;
 def warn_fe_backend_optimization_failure : Warning<"%0">, BackendInfo,
 InGroup, DefaultWarn;
 def note_fe_backend_optimization_remark_invalid_loc : Note<"could "

Modified: cfe/trunk/lib/CodeGen/CodeGenAction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenAction.cpp?rev=244526&r1=244525&r2=244526&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenAction.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenAction.cpp Mon Aug 10 18:05:16 2015
@@ -258,6 +258,8 @@ namespace clang {
 const llvm::DiagnosticInfoOptimizationRemarkAnalysis &D);
 void OptimizationRemarkHandler(
 const llvm::DiagnosticInfoOptimizationRemarkAnalysisFPCommute &D);
+void OptimizationRemarkHandler(
+const llvm::DiagnosticInfoOptimizationRemarkAnalysisAliasing &D);
 void OptimizationFailureHandler(
 const llvm::DiagnosticInfoOptimizationFailure &D);
   };
@@ -513,6 +515,17 @@ void BackendConsumer::OptimizationRemark
 D, diag::remark_fe_backend_optimization_remark_analysis_fpcommute);
 }
 
+void BackendConsumer::OptimizationRemarkHandler(
+const llvm::DiagnosticInfoOptimizationRemarkAnalysisAliasing &D) {
+  // Optimization analysis remarks are active only if the -Rpass-analysis
+  // flag has a regular expression that matches the name of the pass
+  // name in \p D.
+  if (CodeGenOpts.OptimizationRemarkAnalysisPattern &&
+  CodeGenOpts.OptimizationRemarkAnalysisPattern->match(D.getPassName()))
+EmitOptimizationMessage(
+D, diag::remark_fe_backend_optimization_remark_analysis_aliasing);
+}
+
 void BackendConsumer::OptimizationFailureHandler(
 const llvm::DiagnosticInfoOptimizationFailure &D) {
   EmitOptimizationMessage(D, diag::warn_fe_backend_optimization_failure);
@@ -572,6 +585,12 @@ void BackendConsumer::DiagnosticHandlerI
 OptimizationRemarkHandler(
 cast(DI));
 return;
+  case llvm::DK_OptimizationRemarkAnalysisAliasing:
+// Optimization remarks are always handled completely by this
+// handler. There is no generic way of emitting them.
+OptimizationRemarkHandler(
+cast(DI));
+return;
   case llvm::DK_OptimizationFailure:
 // Optimization failures are always handled completely by this
 // handler.

Modified: cfe/trunk/test/Frontend/optimization-remark-options.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/optimization-remark-options.c?rev=244526&r1=244525&r2=244526&view=diff
==
--- cfe/trunk/test/Frontend/optimization-remark-options.c (original)
+++ cfe/trunk/test/Frontend/optimization-remark-options.c Mon Aug 10 18:05:16 
2015
@@ -10,3 +10,12 @@ double foo(int N) {
 
   return v;
 }
+
+// CHECK: {{.*}}:18:13: remark: loop not vectorized: cannot prove pointers 
refer to independent arrays in memory. The loop requires 9 runtime independence 
checks to vectorize the loop, but that would exceed the limit of 8 checks; 
avoid runtime pointer checking when you know the arrays will always be 
independent by specifying '#pragma clang loop vectorize(assume_safety)' before 
the loop or by specifying 'restrict' on the array arguments. Erron

Re: [Patch][LoopVectorize] Late evaluate of runtime pointer check's threshold

[Tyler Nowicki via cfe-commits]

Hi Hal,

Thanks, the patches are committed in r244523 and r244526.

There are two possibilities to give the user control over pointer checking. We 
could add a loop hint option like vectorize(check_safety) that would be a safe 
version of ‘assume_safety’ or we could simply make it always emit the necessary 
pointer checks, no matter how many of them there are, when the loop hint 
vectorize(enable) is specified?

What do you think?

Tyler

> On Aug 9, 2015, at 9:41 PM, Hal Finkel  wrote:
> 
> Hi Tyler,
> 
> This looks very useful.
> 
> Please don't mention '-mllvm -runtime-memory-check-threshold=' in the error 
> message. We should add some clause to #pragma clang loop to control this 
> feature with some associated metadata. '-mllvm' things should not be part of 
> the advertised interface to end users (but that should be a separate set of 
> patches regardless).
> 
> Otherwise, LGTM.
> 
> Thanks again,
> Hal
> 
> - Original Message -
>> From: "Tyler Nowicki" mailto:tnowi...@apple.com>>
>> To: "Hal J. Finkel" mailto:hfin...@anl.gov>>, "Commit 
>> Messages and Patches for LLVM" > <mailto:llvm-comm...@lists.llvm.org>>, "llvm
>> cfe" mailto:cfe-commits@lists.llvm.org>>
>> Cc: "Gerolf Hoflehner" mailto:ghofleh...@apple.com>>
>> Sent: Thursday, August 6, 2015 3:25:26 PM
>> Subject: [Patch][LoopVectorize] Late evaluate of runtime pointer check's 
>> threshold
>> 
>> 
>> Hi,
>> 
>> 
>> This patch extends the patches in ' Late evaluation of vectorization
>> requirements’ (still in review). This makes the num runtime pointer
>> checks test into a late diagnostic so we can give the user a better
>> diagnostic message. Clang appends the diagnostic with options for
>> getting the loop vectorized. Here is an example of the diagnostic
>> the user will see:
>> 
>> 
>> "remark: loop not vectorized: cannot prove pointers refer to
>> independent arrays in memory. The loop requires 9 runtime
>> independence checks to safely vectorize the loop, but that would
>> exceed the limit of 8 checks; increase the number of runtime pointer
>> checks with the compiler option ‘-mllvm
>> -runtime-memory-check-threshold=’. To avoid runtime pointer checking
>> when you know the arrays will always be independent specify ‘#pragma
>> clang loop vectorize(assume_safety)’ before the loop or specify
>> ‘restrict’ on the array arguments. Erroneous results will occur if
>> these options are incorrectly applied."
>> 
>> 
>> The diagnostic is produced when the command line option
>> -Rpass-analysis=loop-vectorize is provided.
>> 
>> 
>> Reviews/comments are much appreciated!
>> 
>> 
>> Tyler
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r244526 - Append options for vectorization when pointer checking threshold is exceeded.

[Tyler Nowicki via cfe-commits]

Oh, sorry about that! I'll make that change.

Tyler

On Mon, Aug 10, 2015 at 4:35 PM, Hal Finkel  wrote:

> - Original Message -
> > From: "Tyler Nowicki via cfe-commits" 
> > To: cfe-commits@lists.llvm.org
> > Sent: Monday, August 10, 2015 6:05:17 PM
> > Subject: r244526 - Append options for vectorization when pointer
> checking threshold is exceeded.
> >
> > Author: tnowicki
> > Date: Mon Aug 10 18:05:16 2015
> > New Revision: 244526
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=244526&view=rev
> > Log:
> > Append options for vectorization when pointer checking threshold is
> > exceeded.
> >
> > Following one of the appended options will allow the loop to be
> > vectorized. We do not include a command line option for modifying
> > the pointer checking threshold because there is no clang-level
> > interface for this currently.
> >
> > Modified:
> > cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> > cfe/trunk/lib/CodeGen/CodeGenAction.cpp
> > cfe/trunk/test/Frontend/optimization-remark-options.c
> >
> > Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> > URL:
> >
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=244526&r1=244525&r2=244526&view=diff
> >
> ==
> > --- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> > (original)
> > +++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Mon Aug
> > 10 18:05:16 2015
> > @@ -49,6 +49,12 @@ def remark_fe_backend_optimization_remar
> >  "allow commutativity by specifying '#pragma clang loop
> >  vectorize(enable)' "
> >  "before the loop or by providing the compiler option
> >  '-ffast-math'">,
> >  BackendInfo, InGroup;
> > +def remark_fe_backend_optimization_remark_analysis_aliasing :
> > Remark<"%0; "
> > +"avoid runtime pointer checking when you know the arrays will
> > always be "
> > +"independent by specifying '#pragma clang loop
> > vectorize(assume_safety)' "
> > +"before the loop or by specifying 'restrict' on the array
> > arguments. "
>
> Hi Tyler,
>
> Sorry I missed this earlier, but this needs to say '__restrict__' (or
> '__restrict') when compiling in C++ mode because 'restrict' is not a valid
> keyword in C++.
>
> Thanks again,
> Hal
>
> > +"Erroneous results will occur if these options are incorrectly
> > applied!">,
> > +BackendInfo, InGroup;
> >  def warn_fe_backend_optimization_failure : Warning<"%0">,
> >  BackendInfo,
> >  InGroup, DefaultWarn;
> >  def note_fe_backend_optimization_remark_invalid_loc : Note<"could "
> >
> > Modified: cfe/trunk/lib/CodeGen/CodeGenAction.cpp
> > URL:
> >
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenAction.cpp?rev=244526&r1=244525&r2=244526&view=diff
> >
> ==
> > --- cfe/trunk/lib/CodeGen/CodeGenAction.cpp (original)
> > +++ cfe/trunk/lib/CodeGen/CodeGenAction.cpp Mon Aug 10 18:05:16 2015
> > @@ -258,6 +258,8 @@ namespace clang {
> >  const llvm::DiagnosticInfoOptimizationRemarkAnalysis &D);
> >  void OptimizationRemarkHandler(
> >  const
> >  llvm::DiagnosticInfoOptimizationRemarkAnalysisFPCommute
> >  &D);
> > +void OptimizationRemarkHandler(
> > +const llvm::DiagnosticInfoOptimizationRemarkAnalysisAliasing
> > &D);
> >  void OptimizationFailureHandler(
> >  const llvm::DiagnosticInfoOptimizationFailure &D);
> >};
> > @@ -513,6 +515,17 @@ void BackendConsumer::OptimizationRemark
> >  D,
> >  diag::remark_fe_backend_optimization_remark_analysis_fpcommute);
> >  }
> >
> > +void BackendConsumer::OptimizationRemarkHandler(
> > +const llvm::DiagnosticInfoOptimizationRemarkAnalysisAliasing &D)
> > {
> > +  // Optimization analysis remarks are active only if the
> > -Rpass-analysis
> > +  // flag has a regular expression that matches the name of the pass
> > +  // name in \p D.
> > +  if (CodeGenOpts.OptimizationRemarkAnalysisPattern &&
> > +
> >
> CodeGenOpts.OptimizationRemarkAna

r244556 - Print vectorization analysis when loop hint is specified.

[Tyler Nowicki via cfe-commits]

Author: tnowicki
Date: Mon Aug 10 20:10:08 2015
New Revision: 244556

URL: http://llvm.org/viewvc/llvm-project?rev=244556&view=rev
Log:
Print vectorization analysis when loop hint is specified.

This patche and a related llvm patch solve the problem of having to explicitly 
enable analysis when specifying a loop hint pragma to get the diagnostics. 
Passing AlwasyPrint as the pass name (see below) causes the front-end to print 
the diagnostic if the user has specified '-Rpass-analysis' without an 
'=’. Users of loop hints can pass that compiler option without 
having to specify the pass and they will get diagnostics for only those loops 
with loop hints.

Added:
cfe/trunk/test/Frontend/optimization-remark-analysis.c
Modified:
cfe/trunk/lib/CodeGen/CodeGenAction.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenAction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenAction.cpp?rev=244556&r1=244555&r2=244556&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenAction.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenAction.cpp Mon Aug 10 20:10:08 2015
@@ -495,33 +495,39 @@ void BackendConsumer::OptimizationRemark
 
 void BackendConsumer::OptimizationRemarkHandler(
 const llvm::DiagnosticInfoOptimizationRemarkAnalysis &D) {
-  // Optimization analysis remarks are active only if the -Rpass-analysis
-  // flag has a regular expression that matches the name of the pass
-  // name in \p D.
-  if (CodeGenOpts.OptimizationRemarkAnalysisPattern &&
-  CodeGenOpts.OptimizationRemarkAnalysisPattern->match(D.getPassName()))
+  // Optimization analysis remarks are active if the pass name is set to
+  // llvm::DiagnosticInfo::AlwasyPrint or if the -Rpass-analysis flag has a
+  // regular expression that matches the name of the pass name in \p D.
+
+  if (D.getPassName() == llvm::DiagnosticInfo::AlwaysPrint ||
+  (CodeGenOpts.OptimizationRemarkAnalysisPattern &&
+   CodeGenOpts.OptimizationRemarkAnalysisPattern->match(D.getPassName(
 EmitOptimizationMessage(
 D, diag::remark_fe_backend_optimization_remark_analysis);
 }
 
 void BackendConsumer::OptimizationRemarkHandler(
 const llvm::DiagnosticInfoOptimizationRemarkAnalysisFPCommute &D) {
-  // Optimization analysis remarks are active only if the -Rpass-analysis
-  // flag has a regular expression that matches the name of the pass
-  // name in \p D.
-  if (CodeGenOpts.OptimizationRemarkAnalysisPattern &&
-  CodeGenOpts.OptimizationRemarkAnalysisPattern->match(D.getPassName()))
+  // Optimization analysis remarks are active if the pass name is set to
+  // llvm::DiagnosticInfo::AlwasyPrint or if the -Rpass-analysis flag has a
+  // regular expression that matches the name of the pass name in \p D.
+
+  if (D.getPassName() == llvm::DiagnosticInfo::AlwaysPrint ||
+  (CodeGenOpts.OptimizationRemarkAnalysisPattern &&
+   CodeGenOpts.OptimizationRemarkAnalysisPattern->match(D.getPassName(
 EmitOptimizationMessage(
 D, diag::remark_fe_backend_optimization_remark_analysis_fpcommute);
 }
 
 void BackendConsumer::OptimizationRemarkHandler(
 const llvm::DiagnosticInfoOptimizationRemarkAnalysisAliasing &D) {
-  // Optimization analysis remarks are active only if the -Rpass-analysis
-  // flag has a regular expression that matches the name of the pass
-  // name in \p D.
-  if (CodeGenOpts.OptimizationRemarkAnalysisPattern &&
-  CodeGenOpts.OptimizationRemarkAnalysisPattern->match(D.getPassName()))
+  // Optimization analysis remarks are active if the pass name is set to
+  // llvm::DiagnosticInfo::AlwasyPrint or if the -Rpass-analysis flag has a
+  // regular expression that matches the name of the pass name in \p D.
+
+  if (D.getPassName() == llvm::DiagnosticInfo::AlwaysPrint ||
+  (CodeGenOpts.OptimizationRemarkAnalysisPattern &&
+   CodeGenOpts.OptimizationRemarkAnalysisPattern->match(D.getPassName(
 EmitOptimizationMessage(
 D, diag::remark_fe_backend_optimization_remark_analysis_aliasing);
 }

Added: cfe/trunk/test/Frontend/optimization-remark-analysis.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/optimization-remark-analysis.c?rev=244556&view=auto
==
--- cfe/trunk/test/Frontend/optimization-remark-analysis.c (added)
+++ cfe/trunk/test/Frontend/optimization-remark-analysis.c Mon Aug 10 20:10:08 
2015
@@ -0,0 +1,21 @@
+// RUN: %clang -O1 -fvectorize -emit-llvm -Rpass-analysis -S %s -o - 2>&1 | 
FileCheck %s --check-prefix=RPASS
+// RUN: %clang -O1 -fvectorize -emit-llvm -S %s -o - 2>&1 | FileCheck %s
+
+// RPASS: {{.*}}:21:1: remark: loop not vectorized: loop contains a switch 
statement
+// CHECK-NOT: {{.*}}:21:1: remark: loop not vectorized: loop contains a switch 
statement
+
+double foo(int N, int *Array) {
+  double v = 0.0;
+
+  #pragma clang loop vectorize(enable)
+  for (int i = 0; i < N; 

r244561 - Make the analysis reporting test with x86 to fix the hexagon build.

[Tyler Nowicki via cfe-commits]

Author: tnowicki
Date: Mon Aug 10 20:54:48 2015
New Revision: 244561

URL: http://llvm.org/viewvc/llvm-project?rev=244561&view=rev
Log:
Make the analysis reporting test with x86 to fix the hexagon build.

Modified:
cfe/trunk/test/Frontend/optimization-remark-analysis.c

Modified: cfe/trunk/test/Frontend/optimization-remark-analysis.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/optimization-remark-analysis.c?rev=244561&r1=244560&r2=244561&view=diff
==
--- cfe/trunk/test/Frontend/optimization-remark-analysis.c (original)
+++ cfe/trunk/test/Frontend/optimization-remark-analysis.c Mon Aug 10 20:54:48 
2015
@@ -1,5 +1,5 @@
-// RUN: %clang -O1 -fvectorize -emit-llvm -Rpass-analysis -S %s -o - 2>&1 | 
FileCheck %s --check-prefix=RPASS
-// RUN: %clang -O1 -fvectorize -emit-llvm -S %s -o - 2>&1 | FileCheck %s
+// RUN: %clang -O1 -fvectorize -target x86_64-unknown-unknown -emit-llvm 
-Rpass-analysis -S %s -o - 2>&1 | FileCheck %s --check-prefix=RPASS
+// RUN: %clang -O1 -fvectorize -target x86_64-unknown-unknown -emit-llvm -S %s 
-o - 2>&1 | FileCheck %s
 
 // RPASS: {{.*}}:21:1: remark: loop not vectorized: loop contains a switch 
statement
 // CHECK-NOT: {{.*}}:21:1: remark: loop not vectorized: loop contains a switch 
statement


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [Patch][LoopVectorize] Print vectorization analysis when loop hint pragma is specified

[Tyler Nowicki via cfe-commits]

Hi Hal, Mark,

These patches solve the problem of having to explicitly enable analysis when 
specifying a loop hint pragma to get the diagnostics. Passing AlwasyPrint as 
the pass name (see below) causes the front-end to print the diagnostic if the 
user has specified '-Rpass-analysis' without an '=’. Users of loop 
hints can pass that compiler option without having to specify the pass and they 
will get diagnostics for only those loops with loop hints.

> const char *Name = Hints.isForced() ? DiagnosticInfo::AlwaysPrint : LV_NAME;

> emitAnalysis(Message, TheFunction, TheLoop, Name);


Mark: Would you be interested in extending this to the loop unroller as well?

> P.S. I assume we should add similar logic to the loop unroller (please add a 
> FIXME if you're not going to do this yourself). Another place where this 
> would be useful is to warn the user when a function marked always_inline is 
> not actually inlined.


Hal: Thanks for the all the reviews Hal!

Committed in r244550, r244552,r244555, and r244556.

Tyler

> On Aug 9, 2015, at 9:59 PM, Hal Finkel  wrote:
> 
> Hi Tyler,
> 
> Thanks for working on this!
> 
> +// If a loop hint is provided the diagnostic is always produced.
> +const char *name = Hints.isForced() ? DiagnosticInfo::AlwaysPrint : 
> LV_NAME;
> 
> name -> Name
> 
> These LGTM.
> 
> P.S. I assume we should add similar logic to the loop unroller (please add a 
> FIXME if you're not going to do this yourself). Another place where this 
> would be useful is to warn the user when a function marked always_inline is 
> not actually inlined.
> 
> -Hal
> 
> - Original Message -
>> From: "Tyler Nowicki" mailto:tnowi...@apple.com>>
>> To: "Gonzalo BG" mailto:gonzalob...@gmail.com>>, 
>> "Hal J. Finkel" mailto:hfin...@anl.gov>>, "Commit Messages 
>> and Patches for LLVM"
>> mailto:llvm-comm...@lists.llvm.org>>, "llvm 
>> cfe" mailto:cfe-commits@lists.llvm.org>>
>> Cc: "Gerolf Hoflehner" mailto:ghofleh...@apple.com>>
>> Sent: Friday, August 7, 2015 4:15:51 PM
>> Subject: [Patch][LoopVectorize] Print vectorization analysis when loop hint 
>> pragma is specified
>> 
>> 
>> Hi,
>> 
>> 
>> 
>> 
>> 
>> Currently, when loop hint is used but vectorization fails we generate
>> a warning. To get the analysis the user needs to provide the command
>> line option -Rpass-analysis= with the correct pass name.
>> BUT we don’t tell the user which pass name they will need to get the
>> analysis message. We should be displaying the analysis without
>> having to request it.
>> 
>> 
>> These patches print the analysis information when vectorization fails
>> on loops with hints when the compiler option ‘-Rpass-analysis’ is
>> provided without ‘='. Users of loop hints can provide the
>> compiler option with their regular debug builds to ensure they
>> always get the analysis when vectorization fails. This approach is
>> preferred because diagnostic printing needs line number tracking
>> which is not enabled by normally. Specifying the option without a
>> pass-target enables line number tracking and makes viewing the
>> messages optional.
>> 
>> 
>> The LLVM patches modify the pass-name of the diagnostic to
>> DiagnosticInfo::AlwaysPrint, which is an empty const char*. The use
>> of DiagnosticInfo::AlwaysPrint is recognized when filtering the
>> diagnostics allowing the message to be printed even if the filter
>> doesn’t match. Note that the analysis of loops with hints will
>> always be printed whenever the compiler option is provided even if
>> ‘=' is specified. This allows both types of analyses to
>> be printed at the same time rather than hiding the analysis on loops
>> with hints with an pass-target is given.
>> 
>> 
>> *These patches build on several previous patches still in review to
>> add late-diagnostics for fp-commut and aliasing. See threads ' Late
>> evaluation of vectorization r equirements’ and ' Late evaluate of
>> runtime pointer check's threshold' .
>> 
>> 
>> Comments and reviews are much appreciated!
>> 
>> 
>> Tyler
>> 
>> 
>> (sorry if you received this twice. I used the wrong mailing list
>> addresses)
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [Patch][LoopVectorize] Print vectorization analysis when loop hint pragma is specified

[Tyler Nowicki via cfe-commits]

Thanks!

Tyler

> On Aug 11, 2015, at 3:27 PM, Mark Heffernan  wrote:
> 
> Nice!
> 
> On Mon, Aug 10, 2015 at 6:57 PM, Tyler Nowicki  <mailto:tnowi...@apple.com>> wrote:
> Mark: Would you be interested in extending this to the loop unroller as well?
> 
> I'd be happy to. I'm about to head off on vacation, but I'll get to it when I 
> return.
> 
> Mark
>  
> 
>> P.S. I assume we should add similar logic to the loop unroller (please add a 
>> FIXME if you're not going to do this yourself). Another place where this 
>> would be useful is to warn the user when a function marked always_inline is 
>> not actually inlined.
> 
> 
> Hal: Thanks for the all the reviews Hal!
> 
> Committed in r244550, r244552,r244555, and r244556.
> 
> Tyler
> 
>> On Aug 9, 2015, at 9:59 PM, Hal Finkel > <mailto:hfin...@anl.gov>> wrote:
>> 
>> Hi Tyler,
>> 
>> Thanks for working on this!
>> 
>> +// If a loop hint is provided the diagnostic is always produced.
>> +const char *name = Hints.isForced() ? DiagnosticInfo::AlwaysPrint : 
>> LV_NAME;
>> 
>> name -> Name
>> 
>> These LGTM.
>> 
>> P.S. I assume we should add similar logic to the loop unroller (please add a 
>> FIXME if you're not going to do this yourself). Another place where this 
>> would be useful is to warn the user when a function marked always_inline is 
>> not actually inlined.
>> 
>> -Hal
>> 
>> - Original Message -
>>> From: "Tyler Nowicki" mailto:tnowi...@apple.com>>
>>> To: "Gonzalo BG" mailto:gonzalob...@gmail.com>>, 
>>> "Hal J. Finkel" mailto:hfin...@anl.gov>>, "Commit 
>>> Messages and Patches for LLVM"
>>> mailto:llvm-comm...@lists.llvm.org>>, "llvm 
>>> cfe" mailto:cfe-commits@lists.llvm.org>>
>>> Cc: "Gerolf Hoflehner" mailto:ghofleh...@apple.com>>
>>> Sent: Friday, August 7, 2015 4:15:51 PM
>>> Subject: [Patch][LoopVectorize] Print vectorization analysis when loop hint 
>>> pragma is specified
>>> 
>>> 
>>> Hi,
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Currently, when loop hint is used but vectorization fails we generate
>>> a warning. To get the analysis the user needs to provide the command
>>> line option -Rpass-analysis= with the correct pass name.
>>> BUT we don’t tell the user which pass name they will need to get the
>>> analysis message. We should be displaying the analysis without
>>> having to request it.
>>> 
>>> 
>>> These patches print the analysis information when vectorization fails
>>> on loops with hints when the compiler option ‘-Rpass-analysis’ is
>>> provided without ‘='. Users of loop hints can provide the
>>> compiler option with their regular debug builds to ensure they
>>> always get the analysis when vectorization fails. This approach is
>>> preferred because diagnostic printing needs line number tracking
>>> which is not enabled by normally. Specifying the option without a
>>> pass-target enables line number tracking and makes viewing the
>>> messages optional.
>>> 
>>> 
>>> The LLVM patches modify the pass-name of the diagnostic to
>>> DiagnosticInfo::AlwaysPrint, which is an empty const char*. The use
>>> of DiagnosticInfo::AlwaysPrint is recognized when filtering the
>>> diagnostics allowing the message to be printed even if the filter
>>> doesn’t match. Note that the analysis of loops with hints will
>>> always be printed whenever the compiler option is provided even if
>>> ‘=' is specified. This allows both types of analyses to
>>> be printed at the same time rather than hiding the analysis on loops
>>> with hints with an pass-target is given.
>>> 
>>> 
>>> *These patches build on several previous patches still in review to
>>> add late-diagnostics for fp-commut and aliasing. See threads ' Late
>>> evaluation of vectorization r equirements’ and ' Late evaluate of
>>> runtime pointer check's threshold' .
>>> 
>>> 
>>> Comments and reviews are much appreciated!
>>> 
>>> 
>>> Tyler
>>> 
>>> 
>>> (sorry if you received this twice. I used the wrong mailing list
>>> addresses)
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> -- 
>> Hal Finkel
>> Assistant Computational Scientist
>> Leadership Computing Facility
>> Argonne National Laboratory
> 
> 

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Improved Diagnostics and Extended vectorize(enable)

[Tyler Nowicki via cfe-commits]

Hi,

I’ve been working on the vectorization diagnostics a little more. The first 
patch makes sure the analysis diagnostics are printed unless a disabling hint 
is provided. And the two pairs of LLVM and Clang patches make the diagnostic 
messages easier to understand and extend the vectorize(enable) hint to override 
the mem-pointer check threshold.

The new diagnostics are:

remark: loop not vectorized: cannot prove it is safe to reorder floating-point 
operations; allow reordering by specifying '#pragma clang loop 
vectorize(enable)' before the loop or by providing the compiler option 
'-ffast-math’.

and

remark: loop not vectorized: cannot prove it is safe to reorder memory 
operations; allow reordering by specifying '#pragma clang loop 
vectorize(enable)' before the loop. If the arrays will always be independent 
specify '#pragma clang loop vectorize(assume_safety)' before the loop or 
provide the '__restrict__' qualifier with the independent array arguments. 
Erroneous results will occur if these options are incorrectly applied!

Using 'vectorize(enable)' to reorder memory operations is always safe (but not 
for fp ops), where as using 'vectorize(assume_safety)' might be dangerous. I 
removed the references to the mem-check threshold because I realized only 
compiler developers would know what it means.

Feedback is appreciated!

Tyler



LLVM-1-LoopVectorizeHints-produces-the-appropriate-pass-name.patch
Description: Binary data


LLVM-2-Modify-diagnostics-to-use-reordering-concept.patch
Description: Binary data


Clang-2-Modify-diagnostics-to-use-reordering-concept.patch
Description: Binary data


LLVM-3-Allow-hint-to-override-memcheck-threshold.patch
Description: Binary data


Clang-3-Allow-hint-to-override-memcheck-threshold.patch
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r246189 - Improve options printed on vectorization analysis diagnostics.

[Tyler Nowicki via cfe-commits]

Author: tnowicki
Date: Thu Aug 27 13:58:34 2015
New Revision: 246189

URL: http://llvm.org/viewvc/llvm-project?rev=246189&view=rev
Log:
Improve options printed on vectorization analysis diagnostics.

The LLVM patch changes the analysis diagnostics produced when loops with

floating-point recurrences or memory operations are identified. The new messages
say "cannot prove it is safe to reorder * operations; allow reordering by   
specifying #pragma clang loop vectorize(enable)". Depending on the type of  
diagnostic the message will include additional options such as ffast-math or
__restrict__.   

Modified:
cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
cfe/trunk/test/Frontend/optimization-remark-options.c

Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=246189&r1=246188&r2=246189&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Thu Aug 27 
13:58:34 2015
@@ -46,13 +46,14 @@ def remark_fe_backend_optimization_remar
 def remark_fe_backend_optimization_remark_analysis : Remark<"%0">, BackendInfo,
 InGroup;
 def remark_fe_backend_optimization_remark_analysis_fpcommute : Remark<"%0; "
-"allow commutativity by specifying '#pragma clang loop vectorize(enable)' "
-"before the loop or by providing the compiler option '-ffast-math'">,
+"allow reordering by specifying '#pragma clang loop vectorize(enable)' "
+"before the loop or by providing the compiler option '-ffast-math'.">,
 BackendInfo, InGroup;
 def remark_fe_backend_optimization_remark_analysis_aliasing : Remark<"%0; "
-"avoid runtime pointer checking when you know the arrays will always be "
-"independent by specifying '#pragma clang loop vectorize(assume_safety)' "
-"before the loop or by specifying 'restrict' on the array arguments. "
+"allow reordering by specifying '#pragma clang loop vectorize(enable)' "
+"before the loop. If the arrays will always be independent specify "
+"'#pragma clang loop vectorize(assume_safety)' before the loop or provide "
+"the '__restrict__' qualifier with the independent array arguments. "
 "Erroneous results will occur if these options are incorrectly applied!">,
 BackendInfo, InGroup;
 def warn_fe_backend_optimization_failure : Warning<"%0">, BackendInfo,

Modified: cfe/trunk/test/Frontend/optimization-remark-options.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/optimization-remark-options.c?rev=246189&r1=246188&r2=246189&view=diff
==
--- cfe/trunk/test/Frontend/optimization-remark-options.c (original)
+++ cfe/trunk/test/Frontend/optimization-remark-options.c Thu Aug 27 13:58:34 
2015
@@ -1,6 +1,6 @@
 // RUN: %clang -O1 -fvectorize -target x86_64-unknown-unknown 
-Rpass-analysis=loop-vectorize -emit-llvm -S %s -o - 2>&1 | FileCheck %s
 
-// CHECK: {{.*}}:9:11: remark: loop not vectorized: vectorization requires 
changes in the order of operations, however IEEE 754 floating-point operations 
are not commutative; allow commutativity by specifying '#pragma clang loop 
vectorize(enable)' before the loop or by providing the compiler option 
'-ffast-math'
+// CHECK: {{.*}}:9:11: remark: loop not vectorized: cannot prove it is safe to 
reorder floating-point operations; allow reordering by specifying '#pragma 
clang loop vectorize(enable)' before the loop or by providing the compiler 
option '-ffast-math'.
 
 double foo(int N) {
   double v = 0.0;
@@ -11,7 +11,7 @@ double foo(int N) {
   return v;
 }
 
-// CHECK: {{.*}}:18:13: remark: loop not vectorized: cannot prove pointers 
refer to independent arrays in memory. The loop requires 9 runtime independence 
checks to vectorize the loop, but that would exceed the limit of 8 checks; 
avoid runtime pointer checking when you know the arrays will always be 
independent by specifying '#pragma clang loop vectorize(assume_safety)' before 
the loop or by specifying 'restrict' on the array arguments. Erroneous results 
will occur if these options are incorrectly applied!
+// CHECK: {{.*}}:18:13: remark: loop not vectorized: cannot prove it is safe 
to reorder memory operations; allow reordering by specifying '#pragma clang 
loop vectorize(enable)' before the loop. If the arrays will always be 
independent specify '#pragma clang loop vectorize(assume_safety)' before the 
loop or provide the '__restrict__' qualifier with the independent array 
arguments. Erroneous results will occur if these options are incorrectly 
applied!
 
 void foo2(int *dw, int *uw, int *A, int *B, int *C, int *D, int N) {
   for (int i = 0; i < N; i++) {


__

Re: [Patch][LoopVectorize]Late evaluation of vectorization requirements

[Tyler Nowicki via cfe-commits]

I’ve updated the patches a bit. I am going post another pair of patches to add another late diagnostic soon as well.Please review,Tyler

LLVM-Late-evaluation-of-vectorization-requirements.patch
Description: Binary data


LLVM-Removed-unused-and-incorrectly-implemented-classof-o.patch
Description: Binary data


Clang-Add-diagnostic-to-append-fp-commute-clang-options-to.patch
Description: Binary data
On Aug 5, 2015, at 1:57 PM, Tyler Nowicki <tnowi...@apple.com> wrote:Hi,Could I get a review of these patches?Thanks,TylerOn Jul 27, 2015, at 4:45 PM, Tyler Nowicki <tnowi...@apple.com> wrote:Please ignore the debug line in the LLVM late-evaluation patch. It won’t be part of the commit.+      DEBUG(dbgs() << "LV: Emitting analysis message.\n”);TylerOn Jul 27, 2015, at 3:23 PM, Tyler Nowicki <tnowi...@apple.com> wrote:Hi Hal,Thanks for the review! No worries about the delay.Could I get a review of these patches for cfe and llvm?Hi Tyler,I'm apologize for the delay. I think this generally looks good, but I don't understand the motivation for introducing the additional FrontendOptions member. Why not just make a subclass of DiagnosticInfoOptimizationRemarkAnalysis that the frontend can handle specially (and detect using the normal isa/dyn_cast mechanism?\The diagnostic handling code doesn’t use isa or dyn_cast, rather it uses switches to select between different types. I modified the patch to use a subclass rather than a member variable. Let me know what patch you think would work out better?I should have also said in my previous email that I am not thrilledby the need to use O3 in the clang-side test.So using -O2 or using -fvectorize does not help?Using -O1 with -fvectorize seems to work, at least it is a smaller set of passes than O3.I attached the updated patches. I also noticed that DiagnosticInfoOptimizationBase::classof() was incorrectly implemented. It would need its own diagnostic kind, but that doesn’t make sense because you would never instantiate the base class. I thought it was best just to remove it. See the third patch.Tyler___cfe-commits mailing listcfe-comm...@cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[Patch][LoopVectorize] Late evaluate of runtime pointer check's threshold

[Tyler Nowicki via cfe-commits]

Hi,This patch extends the patches in 'Late evaluation of vectorization requirements’ (still in review). This makes the num runtime pointer checks test into a late diagnostic so we can give the user a better diagnostic message. Clang appends the diagnostic with options for getting the loop vectorized. Here is an example of the diagnostic the user will see:"remark: loop not vectorized: cannot prove pointers refer to independent arrays in memory. The loop requires 9 runtime independence checks to safely vectorize the loop, but that would exceed the limit of 8 checks; increase the number of runtime pointer checks with the compiler option ‘-mllvm -runtime-memory-check-threshold=’. To avoid runtime pointer checking when you know the arrays will always be independent specify ‘#pragma clang loop vectorize(assume_safety)’ before the loop or specify ‘restrict’ on the array arguments. Erroneous results will occur if these options are incorrectly applied."The diagnostic is produced when the command line option -Rpass-analysis=loop-vectorize is provided.Reviews/comments are much appreciated!Tyler

LLVM-Extend-late-diagnostics-to-include-late-test-for-run.patch
Description: Binary data


Clang-Extended-late-diagnostics-to-ammend-options-related-.patch
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[Patch][LoopVectorize] Print vectorization analysis when loop hint pragma is specified

[Tyler Nowicki via cfe-commits]

Hi,Currently, when loop hint is used but vectorization fails we generate a warning. To get the analysis the user needs to provide the command line option -Rpass-analysis= with the correct pass name. BUT we don’t tell the user which pass name they will need to get the analysis message. We should be displaying the analysis without having to request it. These patches print the analysis information when vectorization fails on loops with hints when the compiler option ‘-Rpass-analysis’ is provided without ‘='. Users of loop hints can provide the compiler option with their regular debug builds to ensure they always get the analysis when vectorization fails. This approach is preferred because diagnostic printing needs line number tracking which is not enabled by normally. Specifying the option without a pass-target enables line number tracking and makes viewing the messages optional.The LLVM patches modify the pass-name of the diagnostic to DiagnosticInfo::AlwaysPrint, which is an empty const char*. The use of DiagnosticInfo::AlwaysPrint is recognized when filtering the diagnostics allowing the message to be printed even if the filter doesn’t match. Note that the analysis of loops with hints will always be printed whenever the compiler option is provided even if ‘=' is specified. This allows both types of analyses to be printed at the same time rather than hiding the analysis on loops with hints with an pass-target is given.*These patches build on several previous patches still in review to add late-diagnostics for fp-commut and aliasing. See threads 'Late evaluation of vectorization requirements’ and 'Late evaluate of runtime pointer check's threshold'.Comments and reviews are much appreciated!Tyler(sorry if you received this twice. I used the wrong mailing list addresses)

Clang-When-Rpass-analysis-is-provided-print-all-analyses.patch
Description: Binary data


LLVM-1-Simplify-processLoop.patch
Description: Binary data


LLVM-2-Moved-LoopVectorizeHints.patch
Description: Binary data


LLVM-3-Modify-pass-name-when-vectorization-fails-with-loop-hints.patch
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r244492 - Append options for floating-point commutivity when related diagnostics are produced.

[Tyler Nowicki via cfe-commits]

Author: tnowicki
Date: Mon Aug 10 14:56:40 2015
New Revision: 244492

URL: http://llvm.org/viewvc/llvm-project?rev=244492&view=rev
Log:
Append options for floating-point commutivity when related diagnostics are 
produced.

With this patch clang appends the command line options that would allow 
vectorization when floating-point commutativity is required. Specifically those 
are enabling fast-math or specifying a loop hint. 

Added:
cfe/trunk/test/Frontend/optimization-remark-options.c
Modified:
cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
cfe/trunk/lib/CodeGen/CodeGenAction.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=244492&r1=244491&r2=244492&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Mon Aug 10 
14:56:40 2015
@@ -45,6 +45,10 @@ def remark_fe_backend_optimization_remar
 InGroup;
 def remark_fe_backend_optimization_remark_analysis : Remark<"%0">, BackendInfo,
 InGroup;
+def remark_fe_backend_optimization_remark_analysis_fpcommute : Remark<"%0; "
+"allow commutativity by specifying ‘#pragma clang loop 
vectorize(enable)’ "
+"before the loop or by providing the compiler option ‘-ffast-math’">,
+BackendInfo, InGroup;
 def warn_fe_backend_optimization_failure : Warning<"%0">, BackendInfo,
 InGroup, DefaultWarn;
 def note_fe_backend_optimization_remark_invalid_loc : Note<"could "

Modified: cfe/trunk/lib/CodeGen/CodeGenAction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenAction.cpp?rev=244492&r1=244491&r2=244492&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenAction.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenAction.cpp Mon Aug 10 14:56:40 2015
@@ -256,6 +256,8 @@ namespace clang {
 const llvm::DiagnosticInfoOptimizationRemarkMissed &D);
 void OptimizationRemarkHandler(
 const llvm::DiagnosticInfoOptimizationRemarkAnalysis &D);
+void OptimizationRemarkHandler(
+const llvm::DiagnosticInfoOptimizationRemarkAnalysisFPCommute &D);
 void OptimizationFailureHandler(
 const llvm::DiagnosticInfoOptimizationFailure &D);
   };
@@ -500,6 +502,17 @@ void BackendConsumer::OptimizationRemark
 D, diag::remark_fe_backend_optimization_remark_analysis);
 }
 
+void BackendConsumer::OptimizationRemarkHandler(
+const llvm::DiagnosticInfoOptimizationRemarkAnalysisFPCommute &D) {
+  // Optimization analysis remarks are active only if the -Rpass-analysis
+  // flag has a regular expression that matches the name of the pass
+  // name in \p D.
+  if (CodeGenOpts.OptimizationRemarkAnalysisPattern &&
+  CodeGenOpts.OptimizationRemarkAnalysisPattern->match(D.getPassName()))
+EmitOptimizationMessage(
+D, diag::remark_fe_backend_optimization_remark_analysis_fpcommute);
+}
+
 void BackendConsumer::OptimizationFailureHandler(
 const llvm::DiagnosticInfoOptimizationFailure &D) {
   EmitOptimizationMessage(D, diag::warn_fe_backend_optimization_failure);
@@ -553,6 +566,12 @@ void BackendConsumer::DiagnosticHandlerI
 OptimizationRemarkHandler(
 cast(DI));
 return;
+  case llvm::DK_OptimizationRemarkAnalysisFPCommute:
+// Optimization remarks are always handled completely by this
+// handler. There is no generic way of emitting them.
+OptimizationRemarkHandler(
+cast(DI));
+return;
   case llvm::DK_OptimizationFailure:
 // Optimization failures are always handled completely by this
 // handler.

Added: cfe/trunk/test/Frontend/optimization-remark-options.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/optimization-remark-options.c?rev=244492&view=auto
==
--- cfe/trunk/test/Frontend/optimization-remark-options.c (added)
+++ cfe/trunk/test/Frontend/optimization-remark-options.c Mon Aug 10 14:56:40 
2015
@@ -0,0 +1,12 @@
+// RUN: %clang -O1 -fvectorize -Rpass-analysis=loop-vectorize -emit-llvm -S %s 
-o - 2>&1 | FileCheck %s
+
+// CHECK: {{.*}}:9:11: remark: loop not vectorized: vectorization requires 
changes in the order of operations, however IEEE 754 floating-point operations 
are not commutative; allow commutativity by specifying ‘#pragma clang loop 
vectorize(enable)’ before the loop or by providing the compiler option 
‘-ffast-math’
+
+double foo(int N) {
+  double v = 0.0;
+
+  for (int i = 0; i < N; i++)
+v = v + 1.0;
+
+  return v;
+}


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D69088: [Lex] #pragma clang transform

[Tyler Nowicki via Phabricator via cfe-commits]

tyler.nowicki added a comment.

In D69088#1713648 , @Meinersbur wrote:

> In D69088#1713623 , @hsaito wrote:
>
> > @Meinersbur, if I remember correctly, there was an RFC discussion on this 
> > topic, right? If yes, would you post the pointer to that? I need a 
> > refresher on what has been discussed/settled in the past.
>
>
> https://lists.llvm.org/pipermail/cfe-dev/2018-May/058141.html


Sorry if this is answered in the patches but what happens if a loop has both 
#pragma clang loop and transform defined before it? I guess it probably 
shouldn't work.

Perhaps instead you could create a new option to indicate that the order should 
be respected.

#pragma clang loop respect_order  <- optionally with (true) or (false)

That approach would avoid the inevitable conflicts of having both loop and 
transform pragmas on the same loop.

(Sorry if you received this twice)


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69088/new/

https://reviews.llvm.org/D69088



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits