diff options
| author | Scott McMurray <scottmcm@users.noreply.github.com> | 2022-04-09 01:27:47 -0700 |
|---|---|---|
| committer | Scott McMurray <scottmcm@users.noreply.github.com> | 2022-05-11 17:16:25 -0700 |
| commit | 89a18cb60053a6c1b3b5f817246ddfd917be1e3e (patch) | |
| tree | 06a98e2a5b6cd45bd0542f91e167f0a15e138779 /compiler/rustc_codegen_llvm/src | |
| parent | 6dd68402c5d7da168f87d8551dd9aed1d8a21893 (diff) | |
| download | rust-89a18cb60053a6c1b3b5f817246ddfd917be1e3e.tar.gz rust-89a18cb60053a6c1b3b5f817246ddfd917be1e3e.zip | |
Add `unsigned_offset_from` on pointers
Like we have `add`/`sub` which are the `usize` version of `offset`, this adds the `usize` equivalent of `offset_from`. Like how `.add(d)` replaced a whole bunch of `.offset(d as isize)`, you can see from the changes here that it's fairly common that code actually knows the order between the pointers and *wants* a `usize`, not an `isize`. As a bonus, this can do `sub nuw`+`udiv exact`, rather than `sub`+`sdiv exact`, which can be optimized slightly better because it doesn't have to worry about negatives. That's why the slice iterators weren't using `offset_from`, though I haven't updated that code in this PR because slices are so perf-critical that I'll do it as its own change. This is an intrinsic, like `offset_from`, so that it can eventually be allowed in CTFE. It also allows checking the extra safety condition -- see the test confirming that CTFE catches it if you pass the pointers in the wrong order.
Diffstat (limited to 'compiler/rustc_codegen_llvm/src')
0 files changed, 0 insertions, 0 deletions
