On 27/07/2026 12:40, Jeffrey Law wrote:
On 7/27/2026 3:46 AM, Richard Earnshaw wrote:
Actually, I've just noticed that you said this was at -O1. If I
compile with -O2 (which is what we generally recommend for general
use), we already generate the eon/and sequence, so I don't think we
need anything more in this case; the problem is just that your
optimization level is too low.
The issue with having patterns that need later splitting is that it
can cause combinatorial explosion problems in the machine description
- we have to start adding yet more patterns to recognize multiple
combinations.
The compilers heuristics are usually very good at handling this
complexity by splitting things as soon as possible. So we try to
stick closely to the 1 insn, 1 instruction rule and only add 1->2+
when there is something very critical that can't be handled by other
optimizations.
I think what got us started down this path was a code quality regression
either with a proposed patch or with something that's gone into the
trunk. Just one more datapoint for the calculus on whether or not to
chase this kind of issue down.
Jeff
If there's a code quality regression, then having A BZ ticket as a first
step is probably warranted. Then we can know to check what might have
regressed (and if need be, what backports might be needed). I didn't
see anything with my build, but I might have been using an older
compiler, or just a different set of default options when configuring
the compiler, all of which may affect outcomes.
R.
