This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH][RFC] Add phiopt in early opts (and add -fssa-phiopt option)
- From: Richard Biener <rguenther at suse dot de>
- To: Jeff Law <law at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Jan Hubicka <hubicka at ucw dot cz>
- Date: Wed, 18 Jun 2014 10:30:06 +0200 (CEST)
- Subject: Re: [PATCH][RFC] Add phiopt in early opts (and add -fssa-phiopt option)
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1406171501490 dot 29270 at zhemvz dot fhfr dot qr> <53A08576 dot 6080704 at redhat dot com>
On Tue, 17 Jun 2014, Jeff Law wrote:
> On 06/17/14 07:07, Richard Biener wrote:
> > I felt that -ftree-XXX is bad naming so I went for -fssa-XXX
> > even if that is now inconsistent. Any optinion here? For
> > RTL we simply have unsuffixed names so shall we instead go
> > for -fphiopt? PHI implies SSA anyway and 'SSA' or 'RTL' is
> > an implementation detail that the user should not be interested
> > in (applies to tree- as well, of course). Now, 'phiopt' is a
> > bad name when thinking of users (but they shouldn't play with
> > those options anyway).
> Our flags are a mess. If I put my user hat on, then I'd have to ask the
> question, why would I care about tree, ssa, or even phis. The pass converts
> branchy code into straightline code. So, arguably, the right name would
> reflect that it changes branchy code to straight line code.
Yeah, but we have so many of those ... well, ideally the user wouldn't
be able to disable random passes with a non-debug option (and we have
-fdisable-tree-XXX to disable individual pass instances).
> But I believe most of our flag names are poor in this regard (and I'm as much
> to blame as anyone). So go with your best judgement IMHO.
> It'd be nice to have some testcases here to show why we want this moved
> earlier so that a few years from now when someone else wants to move it back,
> we can say "umm, see test frobit.c, make that work and you can move it back"
Hmm, yeah. But it's really doing this earlier so it would probably
invoke inliner heuristics and -Os ... I'll try to come up with sth.
For now I have committed the new flag related changes.