r290450 - [PM] Introduce options to enable the (still experimental) new pass

[Chandler Carruth via cfe-commits]

(explicitly adding Richard so he sees this discussion as some of this
involves a discussion between myself and him)

On Tue, Jan 10, 2017 at 4:36 PM Justin Bogner via cfe-commits <
cfe-commits at lists.llvm.org> wrote:

> Chandler Carruth via cfe-commits <cfe-commits at lists.llvm.org> writes:
> > Author: chandlerc
> > Date: Fri Dec 23 14:44:01 2016
> > New Revision: 290450
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=290450&view=rev
> > Log:
> > [PM] Introduce options to enable the (still experimental) new pass
> > manager, and a code path to use it.
> >
> > The option is actually a top-level option but does contain
> > 'experimental' in the name. This is the compromise suggested by Richard
> > in discussions. We expect this option will be around long enough and
> > have enough users towards the end that it merits not being relegated to
> > CC1, but it still needs to be clear that this option will go away at
> > some point.
>
> I don't really understand why this is a driver option and not just a CC1
> option. Using a driver flag makes me think we expect people to be using
> this in production before we make the new PM the default, which seems
> kind of questionable to me,


I tried to explain the thinking here, but sorry if it wasn't clear. And
maybe its just the wrong tradeoff.

My thought process is this: until we get users of Clang and LLVM using the
new PM in production, I think it's going to be between hard and impossible
to make it the default. So I've been trying to make sure we have a healthy
state for asking users to enable this including in production. Speaking
just for myself as a user, I will need to enable this in production prior
to it being the default.


> and I don't see how adding a new
> "-fexperimental" is any better than just using the "-Xclang" that people
> are already familiar with the implications of.
>

The "experimental" thing was not really intended to be anything like the
CC1 interface.

It communicates two things IMO: that the functionality is less mature at
this point, and that there will (eventually) be changes.

I would still expect us to go through a very slow process to remove this
flag, the same as I would expect for any other driver-level flag.

To give an idea of the kind of timeframe I'm trying to prepare for
(although it being faster would of course be a pleasant surprise): I
suspect we will need there to be an open source release with the
functionality finished and reasonably well tested but still not the
default. And in that release we'll want to in the release notes advertise
that this is coming and that the next release will flip the default. And
then I think we'll need to do *another* release where the old pass manager
is still around, but is not the default.

Maybe things will go substantially better/faster than I've described, but
I'm trying to have a plan that is viable even if things move that slowly.


Anyways, if the decision is to go back to a CC1 flag, we can do that. I
just really want to avoid that if possible as I'd like to avoid deploying a
CC1 flag to my users (we work actively to avoid doing this where possible).

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20170110/db4994e4/attachment.html>