Set metadata for vtable-related loads #39995
Conversation
Give LLVM much more information about vtable pointers. Without the extra information, LLVM has to be rather pessimistic about vtables, preventing a number of obvious optimisations. * Makes the vtable pointer argument noalias and readonly. * Marks loads of the vtable pointer as nonnull. * Marks load from the vtable with `!invariant.load` metadata. Fixes rust-lang#39992
|
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
|
LLVM IR before and after this patch: https://gist.github.com/Aatch/fe555f251de910d7e765a11cbb5d78d4 |
|
@bors r+ |
|
📌 Commit 7af3406 has been approved by |
|
⌛ Testing commit 7af3406 with merge 9436c01... |
|
💔 Test failed - status-appveyor |
|
unchanged test: |
|
@bors r=arielb1 |
|
📌 Commit d80cf80 has been approved by |
bluss
added
the
relnotes
Set metadata for vtable-related loads Give LLVM much more information about vtable pointers. Without the extra information, LLVM has to be rather pessimistic about vtables, preventing a number of obvious optimisations. * Makes the vtable pointer argument noalias and readonly. * Marks loads of the vtable pointer as nonnull. * Marks load from the vtable with `!invariant.load` metadata. Fixes rust-lang#39992
Set metadata for vtable-related loads Give LLVM much more information about vtable pointers. Without the extra information, LLVM has to be rather pessimistic about vtables, preventing a number of obvious optimisations. * Makes the vtable pointer argument noalias and readonly. * Marks loads of the vtable pointer as nonnull. * Marks load from the vtable with `!invariant.load` metadata. Fixes rust-lang#39992
Rollup of 28 pull requests - Successful merges: #39859, #39864, #39888, #39903, #39905, #39914, #39945, #39950, #39953, #39961, #39980, #39988, #39993, #39995, #40019, #40020, #40022, #40024, #40025, #40026, #40027, #40031, #40035, #40037, #40038, #40064, #40069, #40086 - Failed merges: #39927, #40008, #40047
|
@Aatch do you have a benchmark/examples for this somewhere? Like to be able to see the "before" and "after" on the generated IR? LLVM devirtualization has improved a lot in the last year (still pretty basic though), but it would be nice to have a couple of "benchmarks" for cases in which we expect a backend to be able to devirtualize calls. That might also help filling LLVM bugs for the cases in which this is not the case, or discover situations in which we are not passing meta-data correctly. |
| let meta = if meta_ty.element_type().kind() == llvm::TypeKind::Pointer { | ||
| b.load_nonnull(meta, None) | ||
| } else { | ||
| b.load(meta, None) |
There was a problem hiding this comment.
None = ABI alignment. Vtables are ABI aligned.
| info.attrs.set(ArgAttribute::NonNull); | ||
| info.attrs.set(ArgAttribute::ReadOnly); |
There was a problem hiding this comment.
Isn't readonly a function attribute? What does this mean when applied to arguments?
There was a problem hiding this comment.
When applied to a pointer argument, it means that the function will only read from it. That allows LLVM to assume that the value behind the pointer won't change across a call to that function.
|
Please take a look at my last comment in #39992 about tight loops and this. |
Give LLVM much more information about vtable pointers. Without the extra
information, LLVM has to be rather pessimistic about vtables, preventing
a number of obvious optimisations.
!invariant.loadmetadata.Fixes #39992