Stream: t-compiler/wg-mir-opt

Topic: mir generated for declarations inside unreachable code?


matthiaskrgr (Jul 19 2020 at 22:26, on Zulip):

I was messing around a bit and it seems that mir is generated for function declarations inside dead code (e..g. if false { ..}), is that something that could be skipped?
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=e0b5d25c6b4554f4d1c06c9dcc4a307f

Félix Fischer (Jul 19 2020 at 22:27, on Zulip):

Yes!

Félix Fischer (Jul 19 2020 at 22:28, on Zulip):

Did it generate that after all the mir-opts?

matthiaskrgr (Jul 19 2020 at 22:28, on Zulip):

hm, I only looked at godbolt and playground so far

matthiaskrgr (Jul 19 2020 at 22:33, on Zulip):

I think it's still there?
fn foo::<impl at bad.rs:6:9: 10:10>::to_string(_1: &foo::A) -> std::string::String {
that's with mirO3

Jonas Schievink (Jul 19 2020 at 22:35, on Zulip):

MIR is built for every function to borrow-check it

Jonas Schievink (Jul 19 2020 at 22:35, on Zulip):

It's also optimized for every function to show const prop warnings

matthiaskrgr (Jul 19 2020 at 22:35, on Zulip):

aaah so the compiler can reject dead-but-invalid code?

Jonas Schievink (Jul 19 2020 at 22:36, on Zulip):

Yeah

Jonas Schievink (Jul 19 2020 at 22:36, on Zulip):

I also think it wouldn't save much time since most functions are reachable

Félix Fischer (Jul 19 2020 at 22:50, on Zulip):

For what it's worth: LLVM does eliminate dead code, so this is only an issue of whether or not to eliminate it at MIR level. Are we all on that boat? :3

matthiaskrgr (Jul 19 2020 at 23:02, on Zulip):

LLVM does eliminate dead code

mmmh https://rust.godbolt.org/z/T4bMnj

nagisa (Jul 19 2020 at 23:29, on Zulip):

the actual answer is "probably not" because Rust doesn’t really preserve distinction of items being declared in dead or not dead code.

nagisa (Jul 19 2020 at 23:29, on Zulip):

only the resolver is affected by scoping of items.

nagisa (Jul 19 2020 at 23:30, on Zulip):

and since implementations of public traits at least generate public symbols, there's no way for LLVM (or rust itself, at that point) to know that these aren’t really used. I think...

nagisa (Jul 19 2020 at 23:30, on Zulip):

if there was an actual analysis that could nuke these public functions/methods, it'd be fairly involved.

nagisa (Jul 19 2020 at 23:31, on Zulip):

In this particular instance it would be necessary to prove that it is impossible to construct an instance of A anywhere.

Félix Fischer (Jul 19 2020 at 23:38, on Zulip):

matthiaskrgr said:

LLVM does eliminate dead code

mmmh https://rust.godbolt.org/z/T4bMnj

I don't think that counts as dead code on a technicality?

Like, yes, that if will never be executed. But all the names declared inside it will enter the binary's namespace. I'm pretty sure that's the case for Rust.

The only thing that will not get executed is the let x = 8; part, which is getting removed from the compiled artifact.

Félix Fischer (Jul 19 2020 at 23:39, on Zulip):

If you for example remove all name declarations and try to do a print and stuff, all of that gets removed: https://rust.godbolt.org/z/1sMjhv

Félix Fischer (Jul 19 2020 at 23:41, on Zulip):

(btw, I changed the flag to check what happened if we upped it from opt-level 2 (=== to -O) to opt-level 3)

Félix Fischer (Jul 19 2020 at 23:45, on Zulip):

And what nagisa is saying is (implicitly) that the names / symbols being declared are public.
And then, that in order to actually remove them you'd need something like a global analysis that proved that those symbols were never being used anywhere in the program.

Félix Fischer (Jul 19 2020 at 23:48, on Zulip):

For what it's worth, it looks to me that the MIR output isn't deleting those lines: https://play.rust-lang.org/?version=nightly&mode=release&edition=2018&gist=203ffc8a5e3fc4cee393bc0737ec8b42

Félix Fischer (Jul 19 2020 at 23:48, on Zulip):

So it looks like LLVM doing all that work of deleting "dead code"

nagisa (Jul 19 2020 at 23:51, on Zulip):

yeah its something LTO can achieve.

nagisa (Jul 19 2020 at 23:51, on Zulip):

or probably thinLTO

Félix Fischer (Jul 19 2020 at 23:54, on Zulip):

Ohh, you mean that maybe LTO can do that proof and delete the code? Damn, LLVM is a beast

Félix Fischer (Jul 19 2020 at 23:54, on Zulip):

Makes sense tho, LTO is where you'd try to do it

Last update: Jan 22 2021 at 13:30UTC