`#[optimize]` does not fully overwrite global opt level in all MIR opts

[RalfJung]

Even after #160524, some passes still use sess.opt_level/sess.mir_opt_level, which means they do not properly honor #[optimize]:

• The inliner has a very special policy where on mir-opt-level 2, behavior depends on the -Copt-level. This is because -Copt-levels 1..=3 all map to the same mir-opt-level but the inliner does not want to behave the same for all of them. I assume we want to preserve this distinction between -Copt-level=1 and higher values (@wesleywiser @cjgillot I think you added this logic in d1d9092, would be good to hear your thoughts on this). If so, we can either just accept that the attribute is not fully equivalent to changing the global opt level, or we could do it properly: map -Copt-level=1 to a different mir-opt-level than the higher -Copt-level values (but is that worth it if the inliner is the only pass making a distinction between the two?).
• dataflow_const_prop passes checks sess.mir_opt_level inside the actual pass to be more or less aggressive. #[optimize] only affects whether the pass is enabled, but then we don't use the attribute later when the pass runs to determine how aggressive it is. See here, here. Not sure what the best way is to deal with this. Maybe we just accept this?

Cc @clubby789 @veluca93 @rust-lang/wg-mir-opt

Tracking issue: #54882

[saethlin]

dataflow_const_prop

I feel like the situation here is just caused by having two MIR opt levels that are beyond what's enabled by -Copt-level=3. I don't know the exact history behind MIR opt levels but I don't think there's a reasonable distinction between MIR opt levels 3 and 4 anymore. They are both a weird sort of "optimize harder" but aren't widely used (but of course there are some users) and we don't actually check that they help in practice.

(I'm just speaking to this pass because I advised the author to add the level 3 vs level 4 behavior)

[RalfJung]

(I'm just speaking to this pass because I advised the author to add the level 3 vs level 4 behavior)

Given that you also said there's no distinction between the two any more -- why did you advise that? Was there still a distinction between them when this check was added?

One of the things I considered doing to resolve the inliner situation is to move all mir opt passes that check level 3 to level 4, and then to say that

• -Copt-level=0 becomes mir-opt-level 1
• -Copt-level=1 becomes mir-opt-level 2
• -Copt-level=2 and higher becomes mir-opt-level 3

The 4 would be the only "optimize harder" level I think. Though we can always start adding checks for level 5. ;)

(And mir-opt-level 0 is defined to mean "preserve all UB", rather than having a separate flag for that with unclear interactions with other flags.)

[saethlin]

why did you advise that?

Because I was naïvely thinking about making use of the MIR opt levels as I saw them at that time, not thinking about whether the MIR opt levels made any sense. I was also interested in giving people access to DataflowConstProp because it's more effective than the old ConstProp, but I suspect GVN has taken care of those optimization opportunities.

Also, it should be noted that the dev guide links to rust-lang/compiler-team#319 as an explanation of what the levels mean, which is a bit of a problem for me because it's describing a reform from a state I wasn't around for to a state I don't think we ever implemented.

I think the system you are describing makes more sense.

[RalfJung]

Also, it should be noted that the dev guide links to rust-lang/compiler-team#319 as an explanation of what the levels mean, which is a bit of a problem for me because it's describing a reform from a state I wasn't around for to a state I don't think we ever implemented.

😂

I think it got partially implemented, we got a new flag to temporarily park broken/unsound optimizations. But yeah, we might be due for another reform...