Uh oh!
There was an error while loading. Please reload this page.
Describe why size_align have not been inlined so far - #79827
Conversation
rust-highfive
commented
Dec 8, 2020
r? @kennytm (rust-highfive has picked a reviewer for you, use r? to override) |
Xanewok
commented
Dec 8, 2020
@bors r+ rollup |
bors
commented
Dec 8, 2020
📌 Commit dc7325e411910d8f325af84c8ad162408249ffa7 has been approved by |
kennytm
commented
Dec 8, 2020
kennytm
commented
Dec 8, 2020
@bors rollup=never |
Xanewok
commented
Dec 8, 2020
Oh, woops, sorry for the noise. It does look innocuous; might be worth adding a comment for posterity on why it's perf-sensitive/the way it is right now. |
Mark-Simulacrum
commented
Dec 8, 2020
r=me with a comment added, fwiw |
Mark-Simulacrum
commented
Dec 8, 2020
(i.e., a comment instead of the current change) |
Xanewok
commented
Dec 9, 2020
For completeness' sake: @bors try @rust-timer queue |
rust-timer
commented
Dec 9, 2020
Awaiting bors try build completion |
bors
commented
Dec 9, 2020
⌛ Trying commit dc7325e411910d8f325af84c8ad162408249ffa7 with merge 69c935bbedf41328fef53fd877e4a48df302d2f5... |
bors
commented
Dec 9, 2020
☀️ Try build successful - checks-actions |
rust-timer
commented
Dec 9, 2020
Queued 69c935bbedf41328fef53fd877e4a48df302d2f5 with parent db85512, future comparison URL. |
rust-timer
commented
Dec 9, 2020
Finished benchmarking try commit (69c935bbedf41328fef53fd877e4a48df302d2f5): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
tmiasko
commented
Dec 9, 2020
Thanks for catching this @kennytm. What prompted me to made this change in the first place, was the number of codegen items created for Given the number of codegen item, the effect on partitioning likely generalizes, although I see no reason to except impact on quality of produced code to be in any particular direction, but since this is not captured by rustc perf benchmarks (except for rustc), leaving this as is seems like a good decision for now. I added a comment describing why the function wasn't inlined so far. |
size_alignsize_align have not been inlined so farkennytm
commented
Dec 9, 2020
@bors rollup |
kennytm
left a comment
There was a problem hiding this comment.
r=me or Mark-Simulacrum after fixing comment
Uh oh!
There was an error while loading. Please reload this page.
bjorn3
commented
Jan 2, 2021
I wonder if calling the size_of and align_of intrinsics directly instead of the |
kennytm
commented
Jan 2, 2021
@bors r+ rollup |
bors
commented
Jan 2, 2021
📌 Commit cf5bd26 has been approved by |
bors
commented
Jan 3, 2021
bors
commented
Jan 3, 2021
☀️ Test successful - checks-actions |
Make `Layout::new::<T>()` a constant instead of multiple NullOps rust-lang#72189 and rust-lang#79827 suggest that this is perf-relevant, so let's see what happens. r? ghost
although it is used only in one place.