diff options
| author | bors <bors@rust-lang.org> | 2021-09-17 01:00:11 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2021-09-17 01:00:11 +0000 |
| commit | 78a46efff06558674b51c10d8d81758285746ab5 (patch) | |
| tree | 74bcd0d53e31967dc52657f64da245acdd61f102 /compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp | |
| parent | e36621057d9f497c822eb800934b5933c10510cf (diff) | |
| parent | 79bc53870f9fb2b25abffedaa3a4823b974fe69f (diff) | |
| download | rust-78a46efff06558674b51c10d8d81758285746ab5.tar.gz rust-78a46efff06558674b51c10d8d81758285746ab5.zip | |
Auto merge of #88832 - pcwalton:debug-unit-variant-fast-path, r=oli-obk
Introduce a fast path that avoids the `debug_tuple` abstraction when deriving Debug for unit-like enum variants. The intent here is to allow LLVM to remove the switch entirely in favor of an indexed load from a table of constant strings, which is likely what the programmer would write in C. Unfortunately, LLVM currently doesn't perform this optimization due to a bug, but there is [a patch](https://reviews.llvm.org/D109565) that fixes this issue. I've verified that, with that patch applied on top of this commit, Debug for unit-like tuple variants becomes a load, reducing the O(n) code bloat to O(1). Note that inlining `DebugTuple::finish()` wasn't enough to allow LLVM to optimize the code properly; I had to avoid the abstraction entirely. Not using the abstraction is likely better for compile time anyway. Part of #88793. r? `@oli-obk`
Diffstat (limited to 'compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp')
0 files changed, 0 insertions, 0 deletions
