On Sat, Aug 29, 2026 at 2:26 AM Aldy Hernandez <[email protected]> wrote: > > On Sat, Aug 29, 2026 at 12:51:22AM -0600, Jeff Law wrote: > > > > On 8/25/26 4:56 AM, Aldy Hernandez wrote: > > > On Mon, Aug 24, 2026 at 08:34:13PM -0600, Jeffrey Law wrote: > > > > > > > Anyway, this is good for trunk. I would suggest exploring if there's > > > > any > > > > negativce fallout from running it unconditionally rather than gated on > > > > !early as a follow-up. > > > Removing the !early_p restriction shows no regressions on trunk. > > > > > > Interestingly, on my corpus of preprocessed files (preprocessed files > > > from a stage1 build) I see we would trigger the optimization 4024 > > > times (3102 early + 922 late) if we remove the !early_p gate, versus > > > 1313 for the gated version. So we seem to be picking up 3X as many as > > > before. > > > > > > I did some quick assembly size comparisons and we have 395 differing > > > translation units for which 178 have less lines and 125 have more > > > lines, for a net reduction of 1997 insns over 14.8M insns. We'd have > > > to run a real benchmark to make sure, but it looks promising. > > > > > > We could remove the gate as a follow-up, since it's easy to revert. > > > Up to you. I did a full regstrap with no regressions. > > > > Yea, let's remove the gate as a follow-up. The committed patch has > > triggered just one very minor sh regression and the code looks better to me > > at a glance, so it's just a scan-asm update, that I'll take care of this > > weekend. > > I'll push the removal of the early_p gate when another round of tests > finishes.
Note I filed 2 related issues dealing with cond_on_phi_p and phi_arg_from_cmp_p. PR 127143 and PR 127144. PR 127143 is the easier of the two and it shows up in phiopt1 due to the factoring of the cast rather than keeping the cast conditional. Note I am not expecting anyone to fix them right away; I am even considering PR 127143 for the early issue of the week. Thanks, Andrea > > Aldy
