This requires a lang ref change for !range or ptr2int and llvm.assume.
Either seems reasonable on first glance.

The expected range seems to be preserved on trunk (16.0) so it this must have been fixed. It might be worth adding the test to the test suite if one doesn't cover this case yet.

$ (set -x && cat llvm-pr46587.ll && opt -S -instcombine llvm-pr46587.ll)
+ cat llvm-pr46587.ll
define float* @f(i64* %ptr) {
entry:
  %val = load i64, i64* %ptr, !range !{i64 64, i64 65536}
  %valptr = inttoptr i64 %val to float*
  ret float* %valptr
}
+ opt -S -instcombine llvm-pr46587.ll
; ModuleID = 'llvm-pr46587.ll'
source_filename = "llvm-pr46587.ll"

define float* @f(i64* %ptr) {
entry:
  %val = load i64, i64* %ptr, align 4, !range !0
  %valptr = inttoptr i64 %val to float*
  ret float* %valptr
}

!0 = !{i64 64, i64 65536}

Hi @msebor,
From what you shared it looks like the reason the range is correct is because no combine has been applied.
Maybe that was an intentional fix to preserve the range information or the reproducer is not enough to expose the issue anymore.

Those seem plausible. I don't have a way to track down the change that preserves the range. In traiging these old reports I've made the assumption that it's helpful to close those that are not reproducible. Please let me know if that's not so or feel free to reopen this report if you think it might still serve a purpose.