> On 8 Sep 2026, at 15:50, Jeff Law <[email protected]> wrote: > > > > On 9/7/26 8:43 AM, [email protected] wrote: >> From: Kyrylo Tkachov <[email protected]> >> >> As promised elsewhere, I've accumulated a number of cleanups and >> modernisations >> of RTL ifcvt while working on the noce_convert_multiple_sets improvements. >> Now that some of the new functionality has landed I'd like to get these >> cleanups in. They are all NFCs: cleaning up comments, factoring out >> bookkeeping duplicate code, moving the noce transforms into a bit more >> structured table-driven form, using some more modern C++ idioms, >> using auto vecs and bitmaps and stuff like that. >> >> They should make it easier to add more transforms in the future. >> >> Bootstrapped and tested on aarch64-none-linux-gnu. > I hate to add more complexity to something like this, but Shreya and I are > nearly ready to embark on cleanups in here too. > > Right now we have all these noce_try_* routines that can synthesize a > branchless sequence. The first one that has a lower cost than a branch wins, > even if there were perhaps other approaches that would be even better. > > Worse yet, we have scenarios today where different targets want radically > different sequences and it's painful to transform one into the other. So any > static ordering is doomed to make some target unhappy from a performance > standpoint. > > > So the thinking was to have the noce_try_* routines return their sequence, > costing and perhaps other data in a structure. The caller would iterate > through all the routines, keeping the best one so far. Once the best is > found, then we'd emit the sequence into the IL and throw away the rest. > > If that's easily rolled into your changes, great. If not, I'd like to land > your changes first since they're likely far more extensive than what Shreya > and I were contemplating.
Thanks for elaborating on the plans. Tbh that seems to only intersect with patch 2 of the series (that Andrea has already commented on). I’m happy to drop/delay that patch, or adjust it to fit your plans. The rest of the patches are much more localized cleanups IMO that should not be controversial (unless I botched up the implementation). From my side, I’d like to extend ifcvt to reason about loop-carried sequences to help with PR126946. This would involve passing down some information to the noce info structs about whether the BBs and values involved are in a loop or loop-carried, and then avoiding lengthening the dependency chains somehow. But that code’s not ready yet. I still intend to send it for stage 1, but it can go after Shreya’s and your changes. Thanks, Kyrill > > Jeff
