On 9/9/26 12:00 AM, Sun Yuechi wrote:
On 9/8/26, Jeff Law wrote:
First , we could check nonzero_bits before making the transformation.
That would allow us to avoid the problem case of 0x80000000 when we have
useful data on bit state.
Second, we could run this pass before combine with your change. That
would give combine the chance to eliminate the sign extension in cases
where it knows the upper 32bits aren't needed. It won't always be
possible, but it may help enough to save this optimization in relatively
common cases.
I think the common case is the loop over the set bits, and neither
seems to help much there. Outside of combine nonzero_bits has no
information about a pseudo, so we'd have to track the definition
ourselves, and in the loop that wouldn't find anything, since the
value comes from the previous iteration. The m != 0 test at the
bottom is a DImode branch, so the extension probably has to stay as
well.
I did some experiments overnight. Running before combine with your
patch to insert the SIGN_EXTEND node seems best to me.
The key realization is that combine will do the bit tracking and will
often find that the SIGN_EXTEND is not necessary and will remove it.
Thus we get the two instruction sequence (ctz+bclr) instead of
(ctz+bclr+sext).
WRT nonzero_bits. They are tracked outside combine, combine just tends
to do a better job. While the current nonzero bits tracking for REGs
outside combine is minimal, there's no strong reason not to use it.
Also note that we *could* do more tracking if we found it useful. We
could register a hook similar to how combine does. It may not matter
for this specific case, but it would have the potential to help
elsewhere. Point being it's an optimization that could potentially
allow us to avoid the SIGN_EXTEND in some cases. But I don't mind
deferring this.
Jeff
