[llvm-dev] RFC: Switching to the new pass manager by default

[Chandler Carruth via llvm-dev]

On Wed, Oct 18, 2017 at 2:28 AM ORiordan, Martin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi Chandler,
>
>
>
> I don’t track the head revisions, instead I do a “Big Bang” update with
> each 6-month formal release of the LLVM suite, and I am now at v5.0.
>
>
>
> Is the implementation of the new pass manager in LLVM v5.0 suitable for me
> to usefully experiment with it so as to provide feedback, or should I wait
> and try it out with v6.0?
>

Unfortunately, some very important fixes landed after 5.0, and the risk was
too high to cherry-pick them to fix an off-by-default feature. LLVM since
the start of August is in a pretty stable state for testing this stuff.

-Chandler


>
>
> Thanks,
>
>
>
>             MartinO
>
>
>
> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *Chandler
> Carruth via llvm-dev
> *Sent:* Wednesday, October 18, 2017 7:51 AM
> *To:* llvm-dev <llvm-dev at lists.llvm.org>
> *Subject:* [llvm-dev] RFC: Switching to the new pass manager by default
>
>
>
> Greetings everyone!
>
>
>
> The new pass manager is getting extremely close to the point where I'm not
> aware of any significant outstanding work needed, and I'd like to see what
> else would be needed to enable it by default. Here are the current
> functionality I'm aware of outstanding:
>
>
>
> 1) Does not do non-trivial loop unswitching. Majority of this is in
> https://reviews.llvm.org/D34200 but will need one or two small follow-ups.
>
>
>
> 2) Currently, sanitizers don't work correctly with it. Thanks to the work
> of others, the missing infrastructure has been added and I'll send a patch
> to wire this up this week.
>
>
>
> 3) Missing support for 'optnone'. I've been working on this, but the
> existing testing wasn't as thorough as I wanted, so it is going slowly.
> I've got about 1/4 of this implemented and should have patches this week or
> next.
>
>
>
> 4) Missing opt-bisect (or similar) facility. This looks pretty trivial to
> add, but I've not even started. If anyone is interested in it, go for it.
> We might even be able to do something simpler using the generic debug
> counters and get equivalent functionality.
>
>
>
> ... that's it?
>
>
>
> Optimization quality / run-time performance:
>
> - We've been using it at Google extensively and are very happy with the
> optimization quality. Benchmarks look *very* good here.
>
> - More data from other users would be important.
>
> - You can try it out with `-fexperimental-new-pass-manager` to Clang
>
>
>
> Compile-time performance:
>
> - Sometimes *much* better due to cached analyses.
>
> - Sometimes worse, typically due to more / different inlining in turn
> running main pipeline (GVN + InstCombine) more times or over more code.
>
> - Overall somewhat a wash, but the increased compile times typically due
> to the optimizer "trying" harder, so not too concerning on our end.
>
> - Again, more feedback from other users good:
> `-fexperimental-new-pass-manager` to Clang
>
>
>
> Once the four missing things land, I'll also happily work on collecting
> some of the basics on the test-suite and CTMark. But I suspect more "in the
> wild" data would really be useful here given the significance of the change.
>
>
>
> Thoughts? What else (beyond the four items above and feedback on run-time
> and compile-time) would folks like to see?
>
>
>
> Once this happens, I'll also be preparing some batch, mechanical updates
> to the test suite to primarily use the new pass manager. Also there is lots
> of documentation updates that will be needed here.
>
>
>
> -Chandler
>
>
>
> PS: I'll be sending a note to cfe-dev as a "heads up" about this
> discussion as in some ways, the default flip is mostly a Clang default
> flip. But hopefully our doc updates will trigger this being "perceived" as
> the default for other frontends, and I'll try to reach out to other major
> frontends as well (Swift and Rust are on my radar, and I've already started
> talking with Philip Reames about their Falcon JIT).
>
> --------------------------------------------------------------
> Intel Research and Development Ireland Limited
> Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> Registered Number: 308263
>
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient(s). Any review or distribution by others
> is strictly prohibited. If you are not the intended recipient, please
> contact the sender and delete all copies.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171018/2de3d8db/attachment.html>