Bug 54959 - current_pass == NULL during invocation of pass->gate within execute_ipa_summary_passes()
Summary: current_pass == NULL during invocation of pass->gate within execute_ipa_summa...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: plugins (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-17 19:28 UTC by Dave Malcolm
Modified: 2015-11-23 11:45 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-10-18 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Malcolm 2012-10-17 19:28:38 UTC
In my gcc-python-plugin I allow users to create custom passes.

(FWIW see http://gcc-python-plugin.readthedocs.org/en/latest/passes.html#creating-new-optimization-passes for what this looks like from the user's perspective).

In particular, I've been supporting a gate() method, mirroring that of the underlying opt_pass.

I have a single impl_gate() handler that's shared by all such user-created passes, which I then dispatch to appropriate python code.  Given that the gate() callback takes no arguments, I've been looking up the relevant opt_pass* by looking at the "current_pass" global.

This works for GIMPLE_PASS passes, but not for those of kind IPA_PASS.

Specifically, within gcc-4.7.0:gcc/passes.c:
  1875	void
  1876	execute_ipa_summary_passes (struct ipa_opt_pass_d *ipa_pass)
  1877	{
  1878	  while (ipa_pass)
  1879	    {
  1880	      struct opt_pass *pass = &ipa_pass->pass;
  1881	
  1882	      /* Execute all of the IPA_PASSes in the list.  */
  1883	      if (ipa_pass->pass.type == IPA_PASS
>>1884		  && (!pass->gate || pass->gate ())
  1885		  && ipa_pass->generate_summary)
  1886		{

at line 1884, pass->gate() is called, but current_pass is NULL, so I don't see to have a way of figuring out which opt_pass* the gate() callback was called on.

Is it possible to set current_pass in this loop before calling gate()?

Alternatively, all such callbacks could gain an argument, passing in "pass" (though that would be an API change).

Hope the above makes sense
Comment 1 Andrew Pinski 2012-10-17 19:48:07 UTC
> I have a single impl_gate() handler that's shared by all such user-created
> passes, which I then dispatch to appropriate python code.

I think this is bad coding.  You should have multiple impl_gate's that then get dispatched to the appropriate python code.
Comment 2 Dave Malcolm 2012-10-17 20:00:05 UTC
The impl_gate is implemented in C, the gate functions in Python.

If I need multiple impl_gate functions, I somehow need to generate machine code at runtime that curry the relevant arguments.

I guess I could use libffi to do this, perhaps, but it seems ugly and fragile.
Comment 3 Richard Biener 2012-10-18 10:05:02 UTC
current_pass is NULL whenever there is no "parent" pass.  It just means that
the overall compile-flow is not encapsulated in a pass (something I run into
when using the statistics code from arbitrary places).
Comment 4 Tom Tromey 2015-11-22 03:51:18 UTC
I think this was fixed back in 2013 when passes were converted to
classes, and gate was made a virtual function:

commit bcfddb5b871250af38e3023c5d26e19fcf524bf2
Author: dmalcolm <dmalcolm@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Mon Aug 5 20:01:43 2013 +0000

    Handwritten part of conversion of passes to C++ classes
[...]
Comment 5 Richard Biener 2015-11-23 11:45:31 UTC
Yeah, 'this' should be used instead of current_pass.