Are there any plans which would get rid of all the
() locals generated? I see they survive until LLVM IR which isn't great.
Yes, but it's blocked on #67191 because otherwise we start not evaluating constants with
() value even if the constant would error if evaluated
We've actually had this optimization but had to roll back out of that reason.
Can't we just keep such constant assignments? What optimization was that?
SimplifyLocals doesn't remove all
() locals though. Some are assigned by calls and those stick around. Maybe we'd want something that could purge all ZST locals?
Hmm... we could replace all
() locals by a constant that is essentially
ptr::dangling(). But I don't see how we can get rid of function return places. They need to have a return place
We could just allow functions to return without a return place. So
_3 = const print() -> [return: bb2, unwind: bb4] would be just
const print() -> [return: bb2, unwind: bb4]. It would make MIR output more readable too =P
I don't think borrowing
() is very common though, we could perhaps keep that. I think every non-returning call making it's own
() local is the problematic case.
Maybe just removing
() locals would help with performance
I wonder if that would interfere with anything @RalfJ wants to rely on
but I generally agree we should strive for less noisy MIR
Miri shouldn't run on optimized MIR at least (if you want to catch UB)
@oli ^^ impedance mismatch :P
we can always overload the
optimized_mir query if we want to (or set the mir opt level low)
@oli Overloading the
optimized_mir query is hard, as
rustc_mir doesn't export any mir passes. Some mir passes are mandatory though, like the generator transform and borrowck.
true, but at mir-opt-level=0 we should only be doing strictly necessary things
I wonder if that would interfere with anything RalfJ wants to rely on
I am not relying on
StorageLive/Dead for anything, really. We are just interpreting them in Miri, giving them concrete meaning, and I am trying to align dataflow analyses assumptions with the meaning they are given there.
I assume with
mir-opt-level=0, none of these optimizations happen? That would be good for Miri's ability to still check that the initially created MIR makes sense.
Yes, that definitely should be the case.