[gomp] Fix -fdump-tree-omplower

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[gomp] Fix -fdump-tree-omplower

Diego Novillo

I'm puzzled about this one.  The dump machinery was registering
pass_lower_omp as an RTL pass.  And this was happening *only* because I
was having pass_lower_omp mark PROP_gimple_any destroyed.

Now, why doesn't this happen to pass_lower_cf?  I cut-n-pasted this from
that one, originally.

Paolo, any ideas why the dump machinery got confused?  The pass itself
ran fine, but it would not react to -fdump-tree-omplower.  It would
only accept -fdump-rtl-omplower and then ICE.

Thanks.


        * omp-low.c (pass_lower_omp): Don't claim to destroy
        PROP_gimple_any.

Index: omp-low.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/Attic/omp-low.c,v
retrieving revision 1.1.2.1
diff -d -u -p -r1.1.2.1 omp-low.c
--- omp-low.c 26 Sep 2005 20:55:40 -0000 1.1.2.1
+++ omp-low.c 26 Sep 2005 23:00:44 -0000
@@ -1175,7 +1175,7 @@ struct tree_opt_pass pass_lower_omp =
   0, /* tv_id */
   PROP_gimple_any, /* properties_required */
   PROP_gimple_lomp, /* properties_provided */
-  PROP_gimple_any, /* properties_destroyed */
+  0, /* properties_destroyed */
   0, /* todo_flags_start */
   TODO_dump_func, /* todo_flags_finish */
   0 /* letter */
Reply | Threaded
Open this post in threaded view
|

Re: [gomp] Fix -fdump-tree-omplower

Paolo Bonzini
Diego Novillo wrote:
> I'm puzzled about this one.  The dump machinery was registering
> pass_lower_omp as an RTL pass.  And this was happening *only* because I
> was having pass_lower_omp mark PROP_gimple_any destroyed.
>
> Now, why doesn't this happen to pass_lower_cf?  I cut-n-pasted this from
> that one, originally.

I don't have the branch checked out, but is PROP_gimple_lomp part of
PROP_trees?

> Paolo, any ideas why the dump machinery got confused?  The pass itself
> ran fine, but it would not react to -fdump-tree-omplower.  It would
> only accept -fdump-rtl-omplower and then ICE.

Which is kind of expected, because it was trying to dump RTL. :-)

Paolo

Reply | Threaded
Open this post in threaded view
|

Re: [gomp] Fix -fdump-tree-omplower

Diego Novillo
On September 27, 2005 03:21, Paolo Bonzini wrote:

> I don't have the branch checked out, but is PROP_gimple_lomp part of
> PROP_trees?
>
I tried that, too.  But it didn't seem to affect things.  I'll try again
with a clean build.
Reply | Threaded
Open this post in threaded view
|

Re: [gomp] Fix -fdump-tree-omplower

Paolo Bonzini-2
>>I don't have the branch checked out, but is PROP_gimple_lomp part of
>>PROP_trees?
>
> I tried that, too.  But it didn't seem to affect things.  I'll try again
> with a clean build.

The reason is that the properties after pass_lower_omp are
PROP_gimple_any if pass_lower_omp did not run, and PROP_gimple_lomp if
pass_lower_omp has run.  register_dump_files sees that pass_lower_omp
has a gate so it takes the "and" of the two to be conservative, and the
result is zero -- no PROP_gimple_any, no PROP_gimple_lomp.

pass_lower_cf has no gate, so it works.  Likewise for pass_lower_eh.

I think that (in retrospect) it was not a good decision to have *only*
mutually exclusive bits PROP_gimple_any, PROP_gimple_lcf,
PROP_gimple_leh.  It would be better to have a single bit
PROP_gimple_any that is always set for GIMPLE code, and then set
PROP_gimple_lcf, PROP_gimple_leh, PROP_gimple_lomp *in addition* to
PROP_gimple_any.

I guess for the branch, the solution is just to not have
PROP_gimple_lomp?  When it is merged, I would take care of fixing it.

Some of this will already be more intuitive in 4.2 after the dump file
naming will be according to your suggestions, and I'll clean up the ugly
code that was only there to keep the old RTL dump file names.

Paolo