On Sun, Sep 28, 2025 at 4:55 PM Andrew Pinski <[email protected]> wrote: > > > > On Sun, Sep 28, 2025, 7:55 AM Andrew Pinski <[email protected]> wrote: >> >> >> >> On Sun, Sep 28, 2025, 7:30 AM YunQiang Su <[email protected]> wrote: >>> >>> Richard Biener <[email protected]> 于2025年9月24日周三 20:36写道： >>> > >>> > On Tue, Sep 23, 2025 at 5:56 AM Andrew Pinski >>> > <[email protected]> wrote: >>> > > >>> > > This is the next patch in the series of removing fab. >>> > > This one is simplier than builtin_constant_p because the only >>> > > time we want to simplify this builtin is at the final folding step. >>> > > >>> > > Note align-5.c needs to change slightly as __builtin_assume_aligned >>> > > is no longer taken into account for the same reason as why PR 111875 >>> > > is closed as invalid and why the testcase is failing at -Og >>> > > I added a new testcase align-5a.c where the pointer is explictly aligned >>> > > so that the check is gone there. >>> > > Note __builtin_assume_aligned should really be instrumented for UBSAN, >>> > > I filed PR 122038 for that. >>> > > >>> > > Bootstrapped and tested on x86_64-linux-gnu. >>> > >>> >>> With this patch, this test case fails on riscv64-linux-gnu >>> gcc.target/riscv/cmo-zicboz-zic64-1.c >> >> >> Can you file a bug report and i will look into it when I get back home from >> the cauldron? > > > Ok, I see the issue. > We now lose __builtin_assume_aligned for expand in some cases. > There are two/three ways of fixing this. One is lowering memset and the > aligning the access type to the new alignment. > > The second way is to prevent forwprop for proping the ssa names from a lower > alignment and replacing the higher one. > That would fix -Og once I finish with set of patches. > > The 3rd way, when removing __builtin_assume_aligned also mark the original > ssa name with the same alignment info if it is only used from the baa. > That means moving this to forwprop only. > > > Let me think which is the best.
You can look at VN/copyprop (IIRC) for cases where we can "back-propagage" this kind of info to the source of the copy. Richard. > > > >> >> Thanks, >> Andrew >> >> >> >>> >>> >>> -- >>> YunQiang Su
