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: [PATCH 3/6] Automated part of conversion of gimple types to use C++ inheritance


On 10/31/13 10:26, David Malcolm wrote:
gcc/

	Patch autogenerated by refactor_gimple.py from
	https://github.com/davidmalcolm/gcc-refactoring-scripts
	revision 74cd3d5f06565c318749d0fb9f35b565dae28daa
[ ... ]
This is fine with the usual conditions.

 diff --git a/gcc/gimple-iterator.c b/gcc/gimple-iterator.c
index e430050..ed0d6df 100644
--- a/gcc/gimple-iterator.c
+++ b/gcc/gimple-iterator.c
@@ -67,7 +67,7 @@ update_bb_for_stmts (gimple_seq_node first, gimple_seq_node last,
  {
    gimple_seq_node n;

-  for (n = first; n; n = n->gsbase.next)
+  for (n = first; n; n = n->next)
So just a quite note. If I'm reading this corectly, this should make things marginally easier in the debugger when looking at objects? It drives me absolutely nuts having to figure out how to get through the base class to the fields I care about.

I didn't look at every hunk in this patch carefully. Just spot checked thigns.


  }

  /* Set the nowait flag on OMP_RETURN statement S.  */
@@ -1661,7 +1973,7 @@ static inline void
  gimple_omp_return_set_nowait (gimple s)
  {
    GIMPLE_CHECK (s, GIMPLE_OMP_RETURN);
-  s->gsbase.subcode |= GF_OMP_RETURN_NOWAIT;
+  s->subcode |= GF_OMP_RETURN_NOWAIT;
So is there some reason the GIMPLE_CHECK was left in here rather than doing the downcasting? This happens in other places.


  }


@@ -1681,8 +1993,9 @@ gimple_omp_return_nowait_p (const_gimple g)
  static inline void
  gimple_omp_return_set_lhs (gimple g, tree lhs)
  {
-  GIMPLE_CHECK (g, GIMPLE_OMP_RETURN);
-  g->gimple_omp_atomic_store.val = lhs;
+  gimple_statement_omp_atomic_store *omp_atomic_store_stmt =
+    as_a <gimple_statement_omp_atomic_store> (g);
+  omp_atomic_store_stmt->val = lhs;
Contrast to prior hunk. This one, AFAICT elimates the GIMPLE_CHECK here and does it as part of the downcasting, right?

I wonder how far we have to go with this before GIMPLE_CHECK goes away :-)


@@ -1723,7 +2038,7 @@ static inline void
  gimple_omp_section_set_last (gimple g)
  {
    GIMPLE_CHECK (g, GIMPLE_OMP_SECTION);
-  g->gsbase.subcode |= GF_OMP_SECTION_LAST;
+  g->subcode |= GF_OMP_SECTION_LAST;
Another example of the GIMPLE_CHECK hanging around.  On purpose?

  }


@@ -1746,9 +2061,9 @@ gimple_omp_parallel_set_combined_p (gimple g, bool combined_p)
  {
    GIMPLE_CHECK (g, GIMPLE_OMP_PARALLEL);
    if (combined_p)
-    g->gsbase.subcode |= GF_OMP_PARALLEL_COMBINED;
+    g->subcode |= GF_OMP_PARALLEL_COMBINED;
    else
-    g->gsbase.subcode &= ~GF_OMP_PARALLEL_COMBINED;
+    g->subcode &= ~GF_OMP_PARALLEL_COMBINED;
Likewise.

  }


@@ -1771,7 +2086,7 @@ gimple_omp_atomic_set_need_value (gimple g)
  {
    if (gimple_code (g) != GIMPLE_OMP_ATOMIC_LOAD)
      GIMPLE_CHECK (g, GIMPLE_OMP_ATOMIC_STORE);
-  g->gsbase.subcode |= GF_OMP_ATOMIC_NEED_VALUE;
+  g->subcode |= GF_OMP_ATOMIC_NEED_VALUE;
Likewise.


And so-on.

I don't see anything objectionable. Just want to make sure the script and/or the by-hand stuff didn't miss some of the conversions.

Jeff




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