https://gcc.gnu.org/bugzilla/show_bug.cgi?id=128379
Bug ID: 128379
Summary: [powerpc64le] Missing ussub<mode>3/sssub<mode>3 for
Altivec; saturating subtract loops are not vectorized
Product: gcc
Version: 17.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jskumari at gcc dot gnu.org
Target Milestone: ---
Altivec has saturating vector subtract instructions: vsububs, vsubuhs, vsubuws,
vsubsbs, vsubshs and vsubsws. They are implemented in altivec.md as
altivec_vsubu<VI_char>s (us_minus:VI) and altivec_vsubs<VI_char>s
(ss_minus:VI). Neither is exposed under the standard optab names ussub<mode>3
or sssub<mode>3.
The middle end finds saturating subtract idioms through .SAT_SUB:
- vect_recog_sat_sub_pattern (tree-vect-patterns.cc) recognizes the idiom in
loops.
- It then calls direct_internal_fn_supported_p (IFN_SAT_SUB, vectype, ...).
- That call resolves to ussub_optab or sssub_optab (internal-fn.def,
DEF_INTERNAL_SIGNED_OPTAB_FN (SAT_SUB, ..., sssub, ussub, ...)).
The rs6000 backend defines no ussub<mode>3 or sssub<mode>3. The support check
therefore fails for V16QI, V8HI and V4SI. The pattern is never applied, and the
loop is vectorized as compare, subtract and select, or not vectorized at all.
