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.
jeff
