This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: Expand oacc kernels after pass_fre

From: Tom de Vries <Tom_deVries at mentor dot com>
To: Richard Biener <rguenther at suse dot de>
Cc: Thomas Schwinge <thomas at codesourcery dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>
Date: Fri, 19 Jun 2015 09:56:12 +0200
Subject: Re: Expand oacc kernels after pass_fre
Authentication-results: sourceware.org; auth=none
References: <546743BC dot 5070804 at mentor dot com> <54678B3D dot 8020009 at mentor dot com> <54730EE7 dot 40000 at mentor dot com> <5474665A dot 4070101 at mentor dot com> <87iocp1d8o dot fsf at kepler dot schwinge dot homeip dot net> <alpine dot LSU dot 2 dot 11 dot 1504220932150 dot 20496 at zhemvz dot fhfr dot qr> <557076A5 dot 7050207 at mentor dot com> <alpine dot LSU dot 2 dot 11 dot 1506080923250 dot 30088 at zhemvz dot fhfr dot qr>

On 08/06/15 09:25, Richard Biener wrote:

On Thu, 4 Jun 2015, Tom de Vries wrote:

   	    {
   	      gsi_next (&gsi);
   	      continue;
diff --git gcc/tree-ssa-sccvn.c gcc/tree-ssa-sccvn.c
index e417a15..449a615 100644
--- gcc/tree-ssa-sccvn.c
+++ gcc/tree-ssa-sccvn.c
@@ -85,6 +85,7 @@ along with GCC; see the file COPYING3.  If not see
   #include "ipa-ref.h"
   #include "plugin-api.h"
   #include "cgraph.h"
+#include "omp-low.h"

   /* This algorithm is based on the SCC algorithm presented by Keith
      Cooper and L. Taylor Simpson in "SCC-Based Value numbering"
@@ -3542,7 +3543,8 @@ visit_use (tree use)
       {
         if (gimple_code (stmt) == GIMPLE_PHI)
   	changed = visit_phi (stmt);
-      else if (gimple_has_volatile_ops (stmt))
+      else if (gimple_has_volatile_ops (stmt)
+	       || gimple_stmt_omp_data_i_init_p (stmt))


No.

What is the intent of these changes?


These are changes to handle the kernels region conservatively, in order to not
undo the omp-lowering before getting to the oacc-parloops pass.


Still it feels too much like the MPX mistake (maintainance cost and
compile-time cost).  How can any pass "undo" omp-lowering?

I'm talking about the rewriting of the variables in terms of.omp_data_i. Passes like copy_prop and fre undo this rewriting, andpropagate the variables from outside the kernels region back into thekernels region, eliminating .omp_data_i.


Thanks,
- Tom

References:
- Re: Expand oacc kernels after pass_fre
  - From: Tom de Vries
- Re: Expand oacc kernels after pass_fre
  - From: Richard Biener

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]