Created attachment 23863 [details]
Case that gets simplified

The ValueTracking analysis only tries to fill up trailing zeros when going through GEPs.
In particular, the analysis doesn't take advantage of the range information that may be available, resulting and suboptimal code.

* Example *

Consider the following snippet:
```
define i1 @test4_gep(i64* %ptr) {
entry:
  %val = load volatile i64, i64* %ptr, !range !{i64 64, i64 65536}
  %valptr = inttoptr i64 %val to float*
  %gep = getelementptr float, float* %valptr, i64 128 
  %res = icmp ugt float* %gep, inttoptr (i64 523 to float*)
  ret i1 %res
}
```

Using the range information this example can be simplified into the following code, since 64 + 4*128 is guaranteed to be bigger than 523:
```
define i1 @test4_gep(i64* %ptr) {
entry:
  %val = load volatile i64, i64* %ptr, !range !{i64 64, i64 65536}
  ret i1 true
}
```

But given ValueTracking doesn't leverage the range information, no simplification happens.

Now, rewrite this code with an add like so:
```
define i1 @test3_add(i64* %ptr) {
entry:
  %val = load volatile i64, i64* %ptr, !range !{i64 64, i64 65536}
  %valPlus512 = add i64 %val, 512
  %res = icmp ugt i64 %valPlus512, 523
  ret i1 %res
}
```

And ValueTracking provides the proper known bits and the simplification can happen.

* To Reproduce *
# Not simplified.
opt -S -instcombine value_tracking_gep.ll  -o -
# Simplified.
opt -S -instcombine value_tracking_add.ll  -o -

Note: I have to use a volatile load to prevent instcombine for dropping the range information. I'll file a separate PR for that.