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. > In the original we have a ctz+addiw+and, with the new sequence we'd have > ctz+bclr+sext. In the first sequence the ctz+addiw can likely > issue/execute in parallel on a 2+ wide design. While the second > sequence is fully sequential as the bclr is a consumer of the ctz output. Agreed, just dropping it is probably the better choice. I'd like to regtest that version once the machine frees up in a few hours and send it as v2, if that sounds OK to you. Thanks, Sun Yuechi
