Stream: t-compiler

Topic: [Code Generation Unit Partitioning] Debug vs Release


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

@davidtwco brought an interesting idea, which I think makes a lot of sense:

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

@Wesley Wiser

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

It would also be nice to have a scheme for when there is no inlining support at all in the codegen backend (aka cg_clif) It could for example not copy functions marked as #[inline] into every cgu that uses them but instead treat them like normal functions.

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

Yeah, for release builds, we'd ideally have large but equally sized CGUs so that we don't waste idle cycles on different cores waiting for large outlier CGUs to finish compiling.

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

For debug (with incremental), we'd really want the CGUs to be as small as possible with no regard to inlining.

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

@bjorn3
YAAAAS. Omg, I completely forgot to bring up the importance of having different backends. Dangit! :face_palm:
Okay, next time.

I think the fact that our current scheme is tailored towards LLVM is somewhat dangerous. We should avoid being too tied to LLVM.

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

I think a scheme like the debug one would work pretty well with cg_clif

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

I think it may make a lot of sense to have separate partitioning schemes per-backend, but I wouldn't hesitate to make improvements today even if they are llvm-only somehow

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

Now I'm kind of wondering how those cg_clif perf runs would look without inlining logic enabled...

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

Adapting it for cg_clif should be much much easier than improving it for cg_llvm, as cg_clif doesn't do any inlining, which means that you don't have to be smart about copying functions. Just don't copy them and don't merge codegen units.

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

simulacrum said:

I think it may make a lot of sense to have separate partitioning schemes per-backend, but I wouldn't hesitate to make improvements today even if they are llvm-only somehow

No, I completely agree... but what I mean is... we should if possible try to not build something too complex that's llvm-based if that meant that further support for other backends would be hindered. Does that make sense?

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

Yeah. I think I agree in general but we should be careful not to overly generalize here since we only have two backends.

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

I disagree :)

I care much more at this point about optimizing the compiler we have today than a future compiler. I do think we should avoid undue complexity if it doesn't make sense, but if that complexity gives us wins, then we should do it.

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

Wesley Wiser said:

For debug (with incremental), we'd really want the CGUs to be as small as possible with no regard to inlining.

On that same line, should we maybe run different mir-opts based on whether or not we're in Release mode? Because if inlining is always slow to compile, maybe we could experiment and ditch other opts that make debug slower to compile as well :3

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

I suspect using different algorithms that tailor to specific use cases will make the overall code simpler since it is trying to juggle fewer concerns.

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

@Félix Fischer Most mir opts reduce the amount of generated LLVM IR enough and thus save LLVM optimization time that it outweighs the cost of optimizing.

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

I think right now we always run mir-opts because like @bjorn3 says, they improve the throughput of LLVM even though we're in debug

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

Including inlining? Although I think the mir-opt for inlining was disabled, wasn't it

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

MIR inlining is always disabled

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

Ohh, okay :)

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

Well "always" in that the only time it gets used is in the mir-opt tests.

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

In terms of normal uses of rustc, it is never run.

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

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

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

And you can't do that on a stable compiler.

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

simulacrum said:

I disagree :)

I care much more at this point about optimizing the compiler we have today than a future compiler. I do think we should avoid undue complexity if it doesn't make sense, but if that complexity gives us wins, then we should do it.

That's fair :)

I dunno, I guess I just worry about the recent LLVM compile-time regressions too much. Also their interests not being all that aligned with ours as well.

Like don't get me wrong, LLVM is a marvel and a gem. Compiler development was a wasteland before LLVM came along.
But... I can't avoid thinking about their path forward diverging from ours in the future.

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

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?

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

If we were in a future land where LLVM wasn't our primary backend, my opinion would definitely be different

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

Wesley Wiser said:

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

Maybe we could run it in Release?

Last update: Jun 04 2020 at 17:30UTC