Applied to master (with all the testcase TLC we could muster) as a48fbdd6a803, thanks! --Philipp.
On Sun, 15 Mar 2026 at 16:33, Jeffrey Law <[email protected]> wrote: > > > On 3/13/2026 12:58 PM, Konstantinos Eleftheriou wrote: > > From: Philipp Tomsich <[email protected]> <[email protected]> > > The redundant-store tracking introduced in ec5349c37af replaced a > safe bitmap_bit_in_range_p check (which bailed on any overlap) with > bitmap_all_bits_in_range_p (which only removed fully redundant stores). > This broke "last writer wins" semantics for partially overlapping > stores: when an earlier store's BFI was applied after the base store's > value, it overwrote bytes that should have belonged to the later store. > > Restore the original overlap check from 1d8de1e93ea: bail out of the > optimization when any bit in a store's byte range is already claimed > by a later store in program order. Remove the now-unnecessary > redundant-store tracking (redundant_stores, store_ind_to_remove). > > gcc/ChangeLog: > > PR rtl-optimization/124476 > * avoid-store-forwarding.cc > (store_forwarding_analyzer::process_store_forwarding): Replace > bitmap_all_bits_in_range_p with bitmap_any_bit_in_range_p and > return false on partial overlap. Remove redundant-store vectors > and their associated removal, dump, and deletion logic. > > gcc/testsuite/ChangeLog: > > PR rtl-optimization/124476 > * gcc.dg/avoid-store-forwarding-1.c: New test. > > It looks like the test has an assumption that longs are at least 64bits > wide. I don't immediately see an effective target test that would allow > you do handle that cleanly. Perhaps just check the size of a long at > runtime and if it's <= 4, just exit with zero status if you can't find a > suitable effective target test. It may also be the case that the test only > works for little endian, so you may need to check that too. > > OK with a little testcase TLC. Thanks for taking care of his. > > jeff >
