On 9/10/26 7:35 PM, sunyuechi wrote:
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
Thanks for the detailed analysis.
One new data point: a colleague tried this patch and, while it does
fix the
DPDK hang, they are also hitting a desktop that fails to start which
is not
fixed by it. So there is likely more to this than the case I have here.
They would like to take over and send a complete fix. I have
forwarded your
comments to them, and they will post a new series rather than a v3 of
this
one.
Note I'm aware of a second issue with that mini-pass that I'm fixing
right now. So if it's another problem with ctz/bclr it could well be
the but I've been analyzing today. For the bug I'm looking at right
now, we're doing two things wrong. First, there's an off-by-one error
in the scan for safety of moving the CTZ. Second, we left the original
AND in the instruction stream causing two bits to be cleared at a time.
So if your colleague is seeing problems that match that particular
behavior, odds are I'll be fixing it for them momentarily :-)
Jeff
