Allow constant-folding intrinsics that are non-pure for inference only

[Keno]

Any constants produced during inference must be exact (in the === to
what would have been produced at runtime sense). As a result, we disallow
constant folding the sqrt intrinsic, since we can't guarantee that this
will be the case (depending on what LLVM decides to do). However, this does
not apply to the optimizer (and in fact we do it all the time by inlining
pure functions here). Thus, for code size, inlining heuristics and non-LLVM
backends, enable the optimizer to constant fold sqrt.

Before:

julia> f() = sqrt(2)
f (generic function with 1 method)

julia> @code_typed f()
CodeInfo(
1 ─ %1 = Base.Math.sqrt_llvm(2.0)::Float64
└──      return %1
) => Float64

julia> @code_typed optimize=false f()
CodeInfo(
1 ─ %1 = Main.sqrt(2)::Float64
└──      return %1
) => Float64

After

julia> @code_typed f()
CodeInfo(
1 ─     return 1.4142135623730951
) => Float64

julia> @code_typed optimize=false f()
CodeInfo(
1 ─ %1 = Main.sqrt(2)::Float64
└──      return %1
) => Float64

Note that we are not able to infer Const, but still inline the
constant in the optimized version of the IR.

[vtjnash]

Yep, this seems like a good step down the road of making a proper @pure interface. I was hoping someone would get to this eventually. All of the _fast intrinsics should be in this list too (of things that can be locally optimized for performance, but are not eligible for inter-proceedural inference). Usually we have just leaned on the knowledge that LLVM already has these optimizations, so this PR is desirable, even though it hasn't been critical.

[vtjnash]

Seems like you're trying to do error checking here, then only get around to doing half of it? I think we can reuse most of pure_eval_call here, rather than implementing an arbitrary subset of it.

[Keno]

ah, oops that code got lost somewhere. I don't think pure_eval_call handles intrinsics though.

[vtjnash]

huh, that seems sort of a little bit silly. I didn't realize we had a third copy of that code sitting around too.

[Keno]

So should I add support for intrinsics to pure_eval_call then? I would kind of like to avoid the try/catch since we do have nothrow modeling for intrinsics.

[Keno]

In any case, I've just added the error check here for now.

[vtjnash]

Yeah, it's probably OK to reuse that support, although a bit less general (can't handle some functions where it might throw, but computing that set is pretty tedious—e.g. sizeof_tfunc). But it doesn't look like you've got any calls to the no-throw predicate right now.

[vtjnash]

Seems to still be missing a call to the nothrow-test or a try/catch to handle it?

[Keno]

Playing with this, an interesting phenomenon that comes us is that other intrinsics in the same function become eligible for constant folding, but since they weren't constant at inference time they don't. I guess that means inlining needs to re-check if all the arguments are constant.

[vtjnash]

Yes, in part that's why I want this to eventually handle as much as the other pure_eval_call paths were also expected to able to handle. I guess we then just need to iterate this pass to convergence? Shouldn't a top-to-bottom pass over the sorted nodes generally already handle most cases though just via SSA value domination?

[vtjnash]

This list should have all of the _fast intrinsics too plus muladd_float. I thought I had remembered to add those to the is_pure_intrinsic_infer list originally, but seems like somehow only sqrt_llvm actually made it on the list—which is arguably the least likely one to actually be a problem.

[vtjnash]

Seems to still be missing a call to the nothrow-test or a try/catch to handle it?

[oscardssmith]

Can this be resurrected?

[Keno]

This particular case was fixed in #43786. We also have the effect system now that says things about this more rigorously, though we don't use it yet here. Regardless, this particular change is outdated.