Uh oh!
There was an error while loading. Please reload this page.
Remove pointer comparison from slice equality - #80209
Conversation
re #71735 (comment): I'm not sure how to test |
Mark-Simulacrum
commented
Dec 20, 2020
Can we use an older version of hyper perhaps? |
Hmm, even circa May 2016, Using
So basically what you'd expect, reverting this makes string comparison marginally slower, but comparing the enum directly is ~the same. Although to be honest I'm not really happy with either my benchmark or what #33892 (comment) describes. Yes, they involve other code, but the only thing that changes is one critical line--basically a microbenchmark with extra steps. But I'm not sure what a good, noncontrived benchmark for this would be. |
Mark-Simulacrum
commented
Dec 23, 2020
I think the codegen test here should probably be changed to test for something we expect to be present, rather than the lack of pointer equality - I am not sure what the IR with this PR looks like, but maybe we can assert that there is a single memcmp generated or something along those lines? I am fine with not trying to test hyper further; I still believe that the check here for pointer equality is unlikely to be impactful in practice (and we know it actively hurts some cases). @bors rollup=never though. |
erikdesjardins
commented
Dec 23, 2020
Changed the test, let me know if you have a better pattern. The old IR is: definezeroexti1@is_zero_slice([4 x i8]* noaliasreadonlyalign1dereferenceable(4) %data) unnamed_addr #0 {
start:
%0 = icmpeq [4 x i8]* %data, getelementptrinbounds (<{ [4 x i8] }>, <{ [4 x i8] }>* @alloc2, i640, i320)
bri1%0, label %"_ZN4core5array103_$LT$impl$u20$core..cmp..PartialEq$LT$$u5b$B$u3b$$u20$N$u5d$$GT$$u20$for$u20$$u5b$A$u3b$$u20$N$u5d$$GT$2eq17h702fd33f1073d678E.exit", label%bb9.i.i.i
bb9.i.i.i: ; preds = %start%1 = getelementptr [4 x i8], [4 x i8]* %data, i640, i640%bcmp.i.i.i = tailcalli32@bcmp(i8*nonnulldereferenceable(4) %1, i8*nonnulldereferenceable(4) getelementptrinbounds (<{ [4 x i8] }>, <{ [4 x i8] }>* @alloc2, i640, i320, i640), i644) #2%2 = icmpeqi32%bcmp.i.i.i, 0brlabel %"_ZN4core5array103_$LT$impl$u20$core..cmp..PartialEq$LT$$u5b$B$u3b$$u20$N$u5d$$GT$$u20$for$u20$$u5b$A$u3b$$u20$N$u5d$$GT$2eq17h702fd33f1073d678E.exit""_ZN4core5array103_$LT$impl$u20$core..cmp..PartialEq$LT$$u5b$B$u3b$$u20$N$u5d$$GT$$u20$for$u20$$u5b$A$u3b$$u20$N$u5d$$GT$2eq17h702fd33f1073d678E.exit": ; preds = %start, %bb9.i.i.i%.0.i.i.i = phii1 [ %2, %bb9.i.i.i ], [ true, %start ]
reti1%.0.i.i.i
}and the new IR is: definezeroexti1@is_zero_slice([4 x i8]* noaliasnocapturereadonlyalign1dereferenceable(4) %data) unnamed_addr #0 {
start:
%0 = getelementptr [4 x i8], [4 x i8]* %data, i640, i640%bcmp.i.i.i = tailcalli32@bcmp(i8*nonnulldereferenceable(4) %0, i8*nonnulldereferenceable(4) getelementptrinbounds (<{ [4 x i8] }>, <{ [4 x i8] }>* @alloc2, i640, i320, i640), i644) #2%1 = icmpeqi32%bcmp.i.i.i, 0reti1%1
} |
Mark-Simulacrum
commented
Dec 23, 2020
Yeah, I think the test is good. We can relax it if it turns out to be too sensitive. @bors r+ rollup=never squash |
bors
commented
Dec 23, 2020
📌 Commit f29b6b8 has been approved by |
bors
commented
Dec 24, 2020
⌛ Testing commit f29b6b8 with merge 280255c7b4b67d559361bdd77d0f1f9c22b073b2... |
rust-log-analyzer
commented
Dec 24, 2020
The job Click to see the possible cause of the failure (guessed by this bot) |
bors
commented
Dec 24, 2020
💔 Test failed - checks-actions |
Mark-Simulacrum
commented
Dec 24, 2020
@bors r+ squash rollup=never |
bors
commented
Dec 24, 2020
📌 Commit fae3ede has been approved by |
bors
commented
Dec 24, 2020
⌛ Testing commit fae3ede with merge 93bac3bc6043448eb0b1de155765fbe6318656ec... |
rust-log-analyzer
commented
Dec 24, 2020
The job Click to see the possible cause of the failure (guessed by this bot) |
bors
commented
Dec 24, 2020
💔 Test failed - checks-actions |
Mark-Simulacrum
commented
Dec 24, 2020
@bors retry |
bors
commented
Dec 25, 2020
⌛ Testing commit fae3ede with merge 80cb6a64ae252b9aa8682fecabd621506106a115... |
rust-log-analyzer
commented
Dec 25, 2020
The job Click to see the possible cause of the failure (guessed by this bot) |
bors
commented
Dec 25, 2020
💔 Test failed - checks-actions |
erikdesjardins
commented
Dec 26, 2020
looks like another spurious failure |
Mark-Simulacrum
commented
Dec 26, 2020
@bors retry |
Remove pointer comparison from slice equality This resurrects rust-lang#71735. Fixesrust-lang#71602, helps with rust-lang#80140. r? `@Mark-Simulacrum`
bors
commented
Dec 26, 2020
bors
commented
Dec 26, 2020
☀️ Test successful - checks-actions |
tesuji
commented
Dec 27, 2020
Why was the PR not auto-closed? Is this a github bug or bors bug? |
It also removes authorship (733cb54), which is unusual; I would expect the resulting commit from this rebase command to have the same author as the first commit from the PR. |
Mark-Simulacrum
commented
Dec 29, 2020
Yeah, those both seem like bors bugs. I will try to investigate later today. |
This resurrects #71735.
Fixes#71602, helps with #80140.
r? @Mark-Simulacrum