Codegen bug with Base.lshr_int intrinsic

[rfourquet]

Ref: https://discourse.julialang.org/t/failure-with-lshr-int-intrinsic-for-on-uint256-type/47738/4
@simeonschaub suggested this repro which "looks like it’s an LLVM bug":

julia> primitive type UInt256 256 end

julia> x = reinterpret(UInt256, rand(UInt128, 2))[]
UInt256(0x48805fdfb72d71fadaf8daa563cf816383f755d9d9e70d703fa348f556c717ad)

julia> f(x) = Base.lshr_int(x, 0x8)
f (generic function with 1 method)

julia> @code_llvm optimize=false f(x)
;  @ REPL[22]:1 within `f'
define void @julia_f_392(i256* noalias nocapture sret %0, i256 %1) {
top:
  %2 = call {}*** @julia.ptls_states()
  %3 = bitcast {}*** %2 to {}**
  %4 = getelementptr inbounds {}*, {}** %3, i64 4
  %5 = bitcast {}** %4 to i64**
  %6 = load i64*, i64** %5
  %7 = lshr i256 %1, 8
  %8 = select i1 true, i256 0, i256 %7
  store i256 %8, i256* %0, align 8
  ret void
}

julia> @code_llvm optimize=true f(x)
;  @ REPL[22]:1 within `f'
define void @julia_f_394(i256* noalias nocapture sret %0, i256 %1) {
top:
  store i256 0, i256* %0, align 8
  ret void
}

[yuyichao]

This is not an LLVM bug but a codegen bug (as the unoptimized version shows). The check for overflow should check the size of the shift amount. If the size of the value (in this case 256) doesn't fit in the shift size (i8) the check should simply be omitted since there's no way the shift can overflow.

[StefanKarpinski]

@Keno, would you be an appropriate person to take a look at this?

[JeffBezanson]

I'll fix it.