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:
1876 execute_ipa_summary_passes (struct ipa_opt_pass_d *ipa_pass)
1878 while (ipa_pass)
1880 struct opt_pass *pass = &ipa_pass->pass;
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)
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
> 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.
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.
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).
I think this was fixed back in 2013 when passes were converted to
classes, and gate was made a virtual function:
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
Yeah, 'this' should be used instead of current_pass.