On 6/11/2026 10:44 PM, Andrew Pinski wrote:
On Wed, Jun 10, 2026 at 5:30 AM Richard Biener
<[email protected]> wrote:
On Sun, Jun 7, 2026 at 8:15 AM Andrew Pinski
<[email protected]> wrote:
This takes https://gcc.gnu.org/pipermail/gcc-patches/2026-June/719384.html
and merge it into factor_out_conditional_operation. Also expands it to
allow for more than just unary and binary operands.
It handles as similar as what ifcvt does in factor_out_operators
but rejects some cases due to those not being profitable.
The cases which are not profitable:
* pointer plus in early with constant operand 1 (except if equal).
* division/mod with constant operand 1
* Complex expr, it would cause to lose an unitialization warning
(gcc.dg/uninit-17.c)
some cases needed to be rejected for validity (copied from ifcvt):
* BIT_FIELD_REF/BIT_INSERT_EXPR (non first operand)
* VEC_PERM_EXPR with constant operand 2
Notes on the testcase changes:
The recip-*.c testcases need to be disable phiopt since it removes
a division in some cases which causes the recip pass not to run.
slsr-12.c and slsr-34.c need to be xfailed. SLSR pass is mostly
in maintaince mode and is not getting improved.
pr122629-1.c and vect-reduc-cond-2.c are now handled in phiopt
rather than ifcvt.
cinc_common_1.c is xfailed because of missing pattern in the aarch64
backend, PR112304.
fuse_cmp_csel.c needed to be updated since the add is now after the
cmp/csel pair and ira puts the constants formation inbetween the cmp/csel.
fuse_cmp_csel-1.c is new version where there is no constant formation.
Looking at the patch shouldn't we decide profitability independent of the
actual operation when there's one constant operand?
I am trying to understand this question. So the profitability in the
case where the operand that is different is constant is NOT
independent from the type of operand and some code depend on the
non-factoring case; e.g. objectsize.
For arithmetic (and logic) operations, factoring is almost always a
good idea because it can lead to phiopt or ifcvt (with cmove). Plus it
will produce slightly smaller code in most cases. You are replacing
one phi with a different one. This code never increases the number of
phis (in the future it might decrease the number).
That is: `a ? b + 1: b + 2` is always better as `b + (a ? 1 : 2)`.
logical operations are similar. Multiply is a wash. shifts are also a
wash.
Not necessarily for RISC-V. The second form tends to lead to more
if-conversion opportunities. You do an sCC on A, increment the result
and add that to b. That's going to be better than computing b+1 and
b+2, then using a pair of czeros+and/ior to select across them. But
this is a general point of friction with most other architectures where
the first form is generally preferred.
Having said that, I'm not going to stress if we prefer the first form in
gimple. We'll do what we can later in the pipeline to convert to the
forms that are more suitable for the target.
Jeff
