On Tue, Jun 23, 2026 at 3:29 PM Jeffrey Law <[email protected]> wrote: > > > > On 6/22/2026 10:35 PM, Andrew Pinski wrote: > > This adds a reduced cs-elim functionality which will be used > > from phiopt. The design is similar to cond_store_replacement except > > we are looking for a similar store right beore the condition. > > This allows for 2 things, the reuse of the same aliasing set and > > second is allows for use in phiopt in a secondary patch. > > > > This can and will be expanded to support the case where there is a > > similar load as the store before the condition for the cases that > > is allowed, e.g. local non-addressable variables or decls when allowing > > race conditions. > > > > Note pr99473-1.c of a case where can be optimized even without > > -fallow-store-data-races now. The store happens before the conditional > > and inside the conditional, so afterwards there is only one store rather > > than 2. The code was also handling it in sink in GCC 12 the same way too > > but now handling it in cselim before sink1. > > > > Bootstrapped and tested on x86_64-linux-gnu. > > > > gcc/ChangeLog: > > > > * tree-ssa-phiopt.cc (cond_store_replacement_limited): New function. > > (pass_cselim::execute): Call cond_store_replacement_limited before > > cond_store_replacement. > > > > gcc/testsuite/ChangeLog: > > > > * gcc.dg/tree-ssa/pr99473-1.c: Remove -fallow-store-data-races as it > > is not > > needed with cond_store_replacement_limited. > Do you expect this work to ultimately provide meaningful infrastructure > to help store elimination in cases like Daniel was looking at earlier > (the bitmap_set_bit/bitmap_clear_bit stuff from spec2017)? I'm trying > to get my plate cleared so that I can help Daniel move that stuff > forward as it represents the largest source of branch mispredicts we're > seeing in 502.gcc.
That was not my motivation here but I do think it can help to provide a meaningful infrastructure for Daniel's work. I think my case 2: + 2) Or the lhs is loaded from right before the condition. Is Daniel's case with a few extra steps dealing with non local variables and such. This RFC only currently handles the case of a store in the front of the conditional (case 1). But I was going to extend it to finish up cases 2 and 3 but I thought I send out an RFC first to make sure it seems like a reasonable way forward. And I wanted to take a break from working on phiopt for this week because I have been stuck on it for this whole release cycle it seems. > > At a high level, if we can get the same overall benefit from cs-elim by > revamping a bit of how phi-opt works, then I'm generally in favor. Yes that is the whole plan/motivation here is to get a revamp up phi-opt to turn it into an if-conversion tool. That will allow for the final phiopt pass to produce COND_EXPR (this was the plan for a couple of years just this release cycle has been time to finish that). Thanks, Andrea > > Jeff
