Stream: t-compiler

Topic: [CGU Partitioning] Debug vs Release


bjorn3 (May 22 2020 at 15:30, on Zulip):

davidtwco said:

Wesley Wiser said:

MIR inlining is always disabled

Do you think inlining in the MIR before partitioning - so that inlining isn't a concern at all during partitioning - could be worthwhile?

MIR inlining happens during the optimized_mir query long before partitioning.

bjorn3 (May 22 2020 at 15:31, on Zulip):

Félix Fischer said:

Wesley Wiser said:

You have to opt-in via -Zmir-opt-level=2

Maybe we could run it in Release?

I believe there are still broken optimizations at that level. At least a while ago there were.

Jonas Schievink (May 22 2020 at 15:31, on Zulip):

Having some release-only MIR opts will happen at some point, I believe – currently we were lucky enough that all MIR opts improve compile times, but that is unlikely to be the case forever.

Félix Fischer (May 22 2020 at 15:31, on Zulip):

bjorn3 said:

Félix Fischer said:

Wesley Wiser said:

You have to opt-in via -Zmir-opt-level=2

Maybe we could run it in Release?

I believe there are still broken optimizations at that level. At least a while ago there were.

Ahh, yes. I meant running the inlining :3

Jonas Schievink (May 22 2020 at 15:32, on Zulip):

Currently though there's still bugs in the inliner and copy-prop passes (and possibly more), so we couldn't just turn on the full level 2 suite

Félix Fischer (May 22 2020 at 15:32, on Zulip):

nono I agree

Alex Crichton (May 22 2020 at 15:33, on Zulip):

FWIW I see y'all talking a lot about cgus and partitioning, and I know a fair bit about what we currently do and would be more than happy to answer questions or talk about it. I don't have a ton of time to implement changes but brain dumps are easier. Feel free to CC me if I can help!

davidtwco (May 22 2020 at 15:33, on Zulip):

(there was more discussion in #t-compiler/meetings > [design meeting] codegen unit partitioning compiler-team#281 that you might not have saw)

pnkfelix (May 22 2020 at 15:34, on Zulip):

(anyone mind if I rename this topic to use "CGU" instead of spelling it out? Its very long in the side bar at the moment and I'd like to add other topics that are also CGU releated)

Félix Fischer (May 22 2020 at 15:34, on Zulip):

I was thinking more on the line of... instead of having "levels" mean both "unstability/unsoundness" and "compile time regressions", having an enum where we had:

Félix Fischer (May 22 2020 at 15:34, on Zulip):

Because there are sound opts in level 2

Félix Fischer (May 22 2020 at 15:35, on Zulip):

pnkfelix said:

(anyone mind if I rename this topic to use "CGU" instead of spelling it out? Its very long in the side bar at the moment and I'd like to add other topics that are also CGU releated)

Oh, I spelled it out so that people not familiar with it could understand what we were talking about :)

Wesley Wiser (May 22 2020 at 15:35, on Zulip):

Alex Crichton said:

FWIW I see y'all talking a lot about cgus and partitioning, and I know a fair bit about what we currently do and would be more than happy to answer questions or talk about it. I don't have a ton of time to implement changes but brain dumps are easier. Feel free to CC me if I can help!

Thanks Alex, that's super helpful!

Wesley Wiser (May 22 2020 at 15:36, on Zulip):

davidtwco said:

Wesley Wiser said:

MIR inlining is always disabled

Do you think inlining in the MIR before partitioning - so that inlining isn't a concern at all during partitioning - could be worthwhile?

I think that is an interesting idea but I'm not sure it would pay off in debug mode where LLVM doesn't inline anyway. For release? Yeah, I think it would.

Wesley Wiser (May 22 2020 at 15:37, on Zulip):

I've done perf runs in the past with the inliner switched on and there are performance improvements.

Félix Fischer (May 22 2020 at 15:37, on Zulip):

OH. We should definitely have this distinction then. Should I open a topic in wg-mir-opt?

Wesley Wiser (May 22 2020 at 15:37, on Zulip):

Seems good, yeah!

Jonas Schievink (May 22 2020 at 15:38, on Zulip):

Oh, you mean fully replace LLVM's inliner with the MIR inliner?

Wesley Wiser (May 22 2020 at 15:44, on Zulip):

I just meant running it in addition to LLVM's since theirs can probably do things ours can't because of query cycles.

Wesley Wiser (May 22 2020 at 15:45, on Zulip):

But for polymorphic functions, if we can generate better MIR that leaves them with less to do, that should be a win.

simulacrum (May 22 2020 at 15:45, on Zulip):

(and also inlining post-llvm optimizations is better, e.g. because it's monomorphized "more")

Félix Fischer (May 22 2020 at 15:51, on Zulip):

simulacrum said:

(and also inlining post-llvm optimizations is better, e.g. because it's monomorphized "more")

Wait, I don't 100% understand what you mean here. Why is it better post-llvm opts? Sorry, I'm a bit sleep deprived today.

Félix Fischer (May 22 2020 at 15:53, on Zulip):

For those interested in following up on the mir-opts specific conversation, here you go:
https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/Debug.20vs.20Release.20opts

Jonas Schievink (May 22 2020 at 15:54, on Zulip):

Yeah that makes sense, but it wouldn't resolve any of the interactions with partitioning, which was mentioned above

Félix Fischer (May 22 2020 at 16:01, on Zulip):

Jonas Schievink said:

Yeah that makes sense, but it wouldn't resolve any of the interactions with partitioning, which was mentioned above

What were you answering to here? Sorry, I think I'm not following where the replies lie anymore >.<

simulacrum (May 22 2020 at 16:03, on Zulip):

Félix Fischer said:

simulacrum said:

(and also inlining post-llvm optimizations is better, e.g. because it's monomorphized "more")

Wait, I don't 100% understand what you mean here. Why is it better post-llvm opts? Sorry, I'm a bit sleep deprived today.

I mean that LLVM's inlining is better able to see, in theory, that e.g. the function being inlined has been removed entirely because it had some complicated logic that worked out to return false; or so

Jonas Schievink (May 22 2020 at 16:03, on Zulip):

I was referring to the response to:

Do you think inlining in the MIR before partitioning - so that inlining isn't a concern at all during partitioning - could be worthwhile?

Félix Fischer (May 22 2020 at 16:11, on Zulip):

simulacrum said:

Félix Fischer said:

simulacrum said:

(and also inlining post-llvm optimizations is better, e.g. because it's monomorphized "more")

Wait, I don't 100% understand what you mean here. Why is it better post-llvm opts? Sorry, I'm a bit sleep deprived today.

I mean that LLVM's inlining is better able to see, in theory, that e.g. the function being inlined has been removed entirely because it had some complicated logic that worked out to return false; or so

Ahh! I see. But this is something that we are also able to do at MIR level. Specially with some of the recent opts, I think we are really close to this exact feature.

There's also two or three things I think?

  1. The fact that we have more information than LLVM does, so most of the opts that we and LLVM both have, happen faster on our side.
  2. That this more or less depends on the order you apply optimizations in.
  3. How prevalent is this case in real codebases? Aren't most functions not reducible to constants?

Anywho. I think I owe you an illustration of where we stand here in mir-opts:

Thing is, I think with those four things you can basically have exactly the same transformation you speak of! So there. I hope I was not too rambly, but I wanted to illustrate that this kind of optimization is also approaching MIR :3

simulacrum (May 22 2020 at 16:12, on Zulip):

We're not trying to nor do I think we can with the small amount of work we've put in match LLVM's insight and ability to remove code -- that's just not really feasible with the tiny amount of resources we've dedicated so far. I do think we can do a lot (and are doing a lot) though!

Félix Fischer (May 22 2020 at 16:13, on Zulip):

Jonas Schievink said:

I was referring to the response to:

Do you think inlining in the MIR before partitioning - so that inlining isn't a concern at all during partitioning - could be worthwhile?

Ahh. I see ^^
@davidtwco they were answering to you there. I'm tagging you so that you don't miss it :)

Félix Fischer (May 22 2020 at 16:14, on Zulip):

simulacrum said:

We're not trying to nor do I think we can with the small amount of work we've put in match LLVM's insight and ability to remove code -- that's just not really feasible with the tiny amount of resources we've dedicated so far. I do think we can do a lot (and are doing a lot) though!

I do agree :)

Félix Fischer (May 22 2020 at 16:15, on Zulip):

Well, still, I think this question has kind of a murky answer... in the sense that we probably need benchmarking to see the nuances

Félix Fischer (May 22 2020 at 16:15, on Zulip):

(@simulacrum)

Josh Triplett (May 22 2020 at 19:16, on Zulip):

I would love to see the performance numbers on a prototype that only pays attention to inline(always), and doesn't mind generating a large number of CGUs.

Josh Triplett (May 22 2020 at 19:17, on Zulip):

The preliminary prototype numbers posted earlier looked great.

Josh Triplett (May 22 2020 at 19:17, on Zulip):

And I definitely agree with the premise that debug should be happy to trade more runtime performance for faster compilation.

Josh Triplett (May 22 2020 at 19:17, on Zulip):

(Within reason.)

Last update: May 29 2020 at 17:00UTC