https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95102
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> One thing that should be done:
> if (_1 < a_4(D))
> goto <bb 4>; [50.00%]
> else
> goto <bb 3>; [50.00%]
>
> <bb 3> [local count: 536870913]:
> x_5 = BIT_INSERT_EXPR <x_3(D), a_4(D), 0>;
>
> <bb 4> [local count: 1073741824]:
> # x_2 = PHI <x_3(D)(2), x_5(3)>
>
>
> Be converted to:
> _1 = BIT_FIELD_REF <x_3(D), 32, 0>;
> nt_6 = BIT_FIELD_REF <x_3(D), 32, 0>;
> if (_1 < a_4(D))
> goto <bb 4>; [50.00%]
> else
> goto <bb 3>; [50.00%]
>
> <bb 3> [local count: 536870913]:
>
> <bb 4> [local count: 1073741824]:
> # nt_7 = PHI <nt_6(2), a_4(D)(3)>
> x_2 = BIT_INSERT_EXPR <x_3(D), nt_7, 0>;
>
> And then normal phiopt would convert it to:
> _1 = BIT_FIELD_REF <x_3(D), 32, 0>;
> nt_7 = MIN <_1, a_4(D);
> x_2 = BIT_INSERT_EXPR <x_3(D), nt_7, 0>;
>
> But this would require a new part of tree-ssa-phiopt which does this, this
> can't be done in match as far as I can tell; I don't know how profitable
> this transfomration is either.
A BIT_INSERT can be quite costly so I'm unsure whether this pays off in
general (without the MIN/MAX detection followup optimization opportunity).
But yes, when constraining it to the case that we insert at the position
we're having one operand of the controlling condition tested it might work.
And sure, why would it not work with match.pd? You can write
(simplify
(cond (lt:c (BIT_FIELD_REF@4 @0 @1 @2) @3) (BIT_INSERT_EXPR @0 @@3 @2) @0)
(if (compare_tree_int (@1, TYPE_PRECISION (TREE_TYPE (@3))))
...
the precision thing is required in case @3 is constant. You could then
transform it to
(bit_insert_expr @0 (cond (lt:c @4 @3) @3 @4) @2)
Note that this will produce a COND_EXPR and not retain the conditional form.
phi-opt could in theory scan the sequence to be inserted for those and
match it up with the existing condition to retain the non-if-converted
control flow but I'm not sure if that's worth the hassle ;)
