`nothrow` analysis not using all the information from type inference

[oscardssmith]

For example, consider Base.infer_effects(>>, (UInt32, Int32)) after #47830 or before #47567. Inference is able to figure out that the error path won't be hit, but the presence of the error path still poisons the effect analysis.

[aviatesk]

If inference is able to figure out that the error path won't be hit, then the :nothrow should not be tainted. Please let me know where exactly the :nothrow effect is tainted.

[oscardssmith]

I'm 90% sure the :nothrow is tainted on

julia/base/operators.jl

Line 690 in c8662b5

throw(MethodError(>>, (x, c)))

[aviatesk]

I don't think so -- can you check it with Cthulhu.descend(...; with_effects=true)?

[jakobnissen]

I've poked around a little. Julia's compiler can't prove that >>(::UInt32, ::Int32) does not hit this line:

julia/base/operators.jl

Line 695 in c8662b5

oftype(x, -1)

(This will error, as -1 is not representable in an UInt32). Julia emits LLVM code including this error:

julia> code_llvm(>>, (UInt32, Int32); optimize=false)
[ lots of elided output]
L30:                                              ; preds = %L26
;  @ operators.jl:707 within `>>`
  %43 = call i32 @j_oftype_618(i32 zeroext %0, i64 signext -1) #0
  call void @llvm.trap()
  unreachable

But LLVM optimises it away. Hence, Julia's inference is not able to figure out the error path will not be hit.

[aviatesk]

Thanks so much @jakobnissen , very helpful. I think it's feasible to improve this analysis on Julia level.