<div dir="ltr">(explicitly adding Richard so he sees this discussion as some of this involves a discussion between myself and him)<br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jan 10, 2017 at 4:36 PM Justin Bogner via cfe-commits <<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Chandler Carruth via cfe-commits <<a href="mailto:cfe-commits@lists.llvm.org" class="gmail_msg" target="_blank">cfe-commits@lists.llvm.org</a>> writes:<br class="gmail_msg">
> Author: chandlerc<br class="gmail_msg">
> Date: Fri Dec 23 14:44:01 2016<br class="gmail_msg">
> New Revision: 290450<br class="gmail_msg">
><br class="gmail_msg">
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=290450&view=rev" rel="noreferrer" class="gmail_msg" target="_blank">http://llvm.org/viewvc/llvm-project?rev=290450&view=rev</a><br class="gmail_msg">
> Log:<br class="gmail_msg">
> [PM] Introduce options to enable the (still experimental) new pass<br class="gmail_msg">
> manager, and a code path to use it.<br class="gmail_msg">
><br class="gmail_msg">
> The option is actually a top-level option but does contain<br class="gmail_msg">
> 'experimental' in the name. This is the compromise suggested by Richard<br class="gmail_msg">
> in discussions. We expect this option will be around long enough and<br class="gmail_msg">
> have enough users towards the end that it merits not being relegated to<br class="gmail_msg">
> CC1, but it still needs to be clear that this option will go away at<br class="gmail_msg">
> some point.<br class="gmail_msg">
<br class="gmail_msg">
I don't really understand why this is a driver option and not just a CC1<br class="gmail_msg">
option. Using a driver flag makes me think we expect people to be using<br class="gmail_msg">
this in production before we make the new PM the default, which seems<br class="gmail_msg">
kind of questionable to me,</blockquote><div><br></div><div>I tried to explain the thinking here, but sorry if it wasn't clear. And maybe its just the wrong tradeoff.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> and I don't see how adding a new<br class="gmail_msg">
"-fexperimental" is any better than just using the "-Xclang" that people<br class="gmail_msg">
are already familiar with the implications of.<br class="gmail_msg"></blockquote><div><br></div><div>The "experimental" thing was not really intended to be anything like the CC1 interface.</div><div><br></div><div>It communicates two things IMO: that the functionality is less mature at this point, and that there will (eventually) be changes.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>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).</div><div><br></div><div>-Chandler</div></div></div>