Interprocedural info based on optimized IR can be invalid

[ianatol]

Discussing our approach here with Keno and he mentioned the following problem with using info based on ipo analysis of optimized IR:

Keno:

There's also the challenge that information derived from optimized IR does not technically need to be interprocedurally valid

So I'm not sure it's really legal to do any interprocedural analysis on optimized IR

Ian:

Ok, didn't know that! We kind of do it in the middle of optimization, so I wonder when that ipo validity is officially thrown out. Is there an issue or something related to that or just a promise we don't keep once we start optimizing?

Keno:

Optimization is allowed to do constant folding that inference isn't allowed to do

So e.g.: if (@fasthmath 1.0 + prevfloat(floatmin(Float64)) - 1.0) > 0.0; return false; else; return true; end

That needs to be opaque to inference, but the optimizer may use fastmath semantics to just change this to either return true and return false. However, if you use that to conclude that this function always returns that you end up in trouble, because if it runs in the optimizer, you can get the other result, so the result is not ipo-safe

We could maybe change the optimizer semantics to preserve ipo safety until LLVM, but it's unclear whether that's the right thing to do

Not a pressing issue but figured it'd be worth keeping in mind for our work here.

[vtjnash]

Ah, yeah, that constant prop example is a good reminder of why we need to be careful with how we treat this. It is for generally that same sort of reason that we are careful not to rerun inference on optimized code in other cases too. I think we can run this to get the inter-procedural information after SROA and slots2ssa, but generally not after any other optimizations. Though locally, we can run it again whenever we want to–it is only IPO that we cannot transfer information.