This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: pass manager question
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Sandra Loosemore <sandra at codesourcery dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 3 Oct 2017 17:17:58 +0200
- Subject: Re: pass manager question
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jakub at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 234D45F2963
- References: <59D29309.2030100@codesourcery.com> <20171003113611.tmqxy6ryu5as7hxz@virgil.suse.cz> <a4f09e3b-0035-945a-aadd-33be91b04f6d@redhat.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Oct 03, 2017 at 09:11:05AM -0600, Jeff Law 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.
> I was thinking that it would be useful to be able to make this kind of
> query as well.
We have properties which the passes can set, of course their number is
limited and using those would require changes to the generic code.
> > 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.
> And as a cleanup that flag ought to be able to replace some of the
> existing state flags. I'm thinking about reload_in_progress,
> reload_completed, cse_not_expected and likely others.
As we have hundreds of passes, it would have to be a per-cfun
sbitmap or something similar, with perhaps named bit positions
for the standard generic passes and a way to get bit positions for the
others (or always look up the pass number)?
Jakub