Interprocedural info based on optimized IR can be invalid

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.

No file, test, or entry point is named. Start by locating the IPO analysis and inference paths that consume optimized IR, then trace where optimizer fastmath semantics can invalidate interprocedural conclusions. Done requires a decided contract for IPO safety and a regression test covering the differing inference and optimization results.

Written by the indexing model from the issue text.