On 10/03/2017 10:45 AM, Sandra Loosemore wrote:
On 10/03/2017 05:36 AM, Martin Jambor wrote:
Hi,
On Mon, Oct 02, 2017 at 01:27:05PM -0600, Sandra Loosemore wrote:
Is there an idiom for target-specific back end code to ask the pass
manager
if a particular pass (e.g., "split1") has already run?
(I might be wrong but) I don't think there is. But it might be a
useful thing to have generally, it would allow us for example to merge
early SRA and "late" SRA which differ in behavior only because the
first one must not touch aggregates that pass_stdarg will operate on.
And I guess the infrastructure to do that could be as simple as adding
a flag (or a counter) to class opt_pass that the pass manager would
set (or increment) when running the pass.
When I was looking at this, I saw that there is already the
static_pass_number field already in the pass object, but it's documented
as being used only for dump file names, so I don't know if that's a
suitable counter or not. Also there's a variable that holds the current
pass object, and a function for looking up a pass by name.
A lot of my confusion has to do with when the numbers are assigned and
what the extent of the information is (since functions can be compiled
with different optimization settings). So, even if this would all "just
work" using the existing code, I think we'd need to document an external
interface for this purpose, even if only in the form of comments in the
code.
I dug around in this further last night and did some experiments. It
looks like static_pass_number is already too overloaded with other
meanings to be appropriate for this enumeration (and e.g. I noticed that
target-specific passes are assigned higher numbers no matter where they
appear in the pass list). But, I think I see how I could do this using
a separate counter field and copying the traversal code from
-fdump-passes, which does get the ordering right. I'll see if I can
work up a patch.
-Sandra
