https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92651
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |missed-optimization
CC|rguenther at suse dot de |rguenth at gcc dot
gnu.org
Target Milestone|--- |10.0
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, we expand from
_1 = (int) a_4(D);
_2 = (int) b_5(D);
_3 = _1 - _2;
isum_6 = ABS_EXPR <_3>;
return isum_6;
where ABS_EXPR expansion seems to like using smax (and if not smax then
conditional move).
(insn 11 10 12 (parallel [
(set (reg:SI 93)
(minus:SI (reg:SI 91)
(reg:SI 92)))
(clobber (reg:CC 17 flags))
]) "t3.c":3:30 -1
(nil))
(insn 12 11 13 (parallel [
(set (reg:SI 94)
(neg:SI (reg:SI 93)))
(clobber (reg:CC 17 flags))
]) "t3.c":3:9 -1
(nil))
(insn 13 12 14 (parallel [
(set (reg:SI 90 [ isum ])
(smax:SI (reg:SI 93)
(reg:SI 94)))
(clobber (reg:CC 17 flags))
]) "t3.c":3:9 -1
(nil))
expand_abs_nojump first looks for an abs pattern (which we have none - but
STV to the rescue!) and then uses MAX(x, -x) if we have a max pattern
which we now have, thanks to r277481. That would turn into a cmov
sequence later in case STV finds the transform not worthwhile.
For corei7:
Computing gain for chain #1...
Instruction gain 8 for 13: {r90:SI=smax(r93:SI,r94:SI);clobber flags:CC;}
REG_DEAD r94:SI
REG_DEAD r93:SI
REG_UNUSED flags:CC
Instruction conversion gain: 8
Registers conversion cost: 6
Total gain: 2
while the rev. wasn't intended to cover abs() it was intended to cover
cmov because cmov exhibits weird performance characteristics and the
lack of min/max (and here abs) instructions on the GPR side is quite bad.
