On Wed, May 27, 2026 at 10:33:00AM +0530, jeevitha wrote:
> Hi All,
>
> The following changes have been bootstrapped and regression tested on
> powerpc64le-linux. Is this okay for trunk?
>
> Changes from V3
> * Renamed ENB_FUTUREV and BSTZ_FUTUREV.
> * Added subheading in extend.texi.
>
> Changes from V2:
> * Added TARGET_VSX check to all new insn patterns.
> * Added * prefix to vsx_mul pattern.
> * Added new test cases vsx_simd-3.c and vsx_simd-4.c.
> * Created new future-vsx stanza to map builtins.
>
> Changes from V1:
> * Incorporated wording suggestions.
> * Renamed mode iterators to VIMulH and VIArith for better clarity.
> * Removed extra blank line in vsx_simd-*.c test case.
> * Replaced unspec with proper smul_highpart and umul_highpart RTL
> codes for multiply-high patterns.
> * Added * prefix to internal patterns for vsx_add, vsx_sub, altivec_add,
> altivec_sub, altivec_smul and altivec_umul.
> * Updated extend.texi.
>
> This patch adds support for VSX vector arithmetic instructions that may
> be added to future PowerPC processors. Note that the names of these
> builtins may change in the future.
>
> New VSX patterns are added for vector add, subtract, multiply, and
> multiply-high instructions guarded by TARGET_FUTURE. Existing Altivec
> patterns are renamed to altivec_* to avoid name conflicts.
>
> 2026-05-27 Jeevitha Palanisamy <[email protected]>
>
> gcc/
> * config/rs6000/altivec.md (*vsx_add<mode>3): New insn pattern.
> (*altivec_add<mode>3): Renamed from add<mode>3.
> (*vsx_sub<mode>3): New insn pattern.
> (*altivec_sub<mode>3): Renamed from sub<mode>3.
Initially I thought that we should put the vsx_ insns in vsx.md, but
this becomes complicated, in that we have to make sure the the VSX
patterns get scanned before the Altivec patterns.
But generally it can be jarring having vsx_ things in altivec.md.
For example, we essentially had:
(define_mode_iterator VI2 [V4SI V8HI V16QI V2DI])
(define_insn "add<mode>3"
[(set (match_operand:VI2 0 "register_operand" "=v")
(plus:VI2 (match_operand:VI2 1 "register_operand" "v")
(match_operand:VI2 2 "register_operand" "v")))]
"<VI_unit>"
"vaddu<VI_char>m %0,%1,%2"
[(set_attr "type" "vecsimple")])
And your code changes this to:
(define_mode_iterator VI2 [V16QI V8HI V4SI V2DI])
(define_mode_iterator VEC_I [V16QI V8HI V4SI V2DI])
(define_mode_iterator VIArith [V8HI V4SI])
(define_expand "add<mode>3"
[(set (match_operand:VEC_I 0 "register_operand")
(plus:VEC_I (match_operand:VEC_I 1 "register_operand")
(match_operand:VEC_I 2 "register_operand")))]
"VECTOR_UNIT_ALTIVEC_OR_VSX_P (<MODE>mode)"
"")
(define_insn "*vsx_add<mode>3"
[(set (match_operand:VIArith 0 "vsx_register_operand" "=wa")
(plus:VIArith (match_operand:VIArith 1 "vsx_register_operand" "wa")
(match_operand:VIArith 2 "vsx_register_operand" "wa")))]
"TARGET_FUTURE && TARGET_VSX"
"xvaddu<VI_char>m %x0,%x1,%x2")
(define_insn "*altivec_add<mode>3"
[(set (match_operand:VEC_I 0 "register_operand" "=v")
(plus:VEC_I (match_operand:VEC_I 1 "register_operand" "v")
(match_operand:VEC_I 2 "register_operand" "v")))]
"<VI_unit>"
"vaddu<VI_char>m %0,%1,%2"
[(set_attr "type" "vecsimple")])
Now for altivec_add<mode>3, I would suggest rejecting the V4SImode and
V2DImode patterns on future systems, such as (even if it is in the same
file):
(define_insn "*altivec_add<mode>3"
[(set (match_operand:VEC_I 0 "register_operand" "=v")
(plus:VEC_I (match_operand:VEC_I 1 "register_operand" "v")
(match_operand:VEC_I 2 "register_operand" "v")))]
"<VI_unit>
&& (!TARGET_FUTURE || <MODE>mode == V16QI || <MODE>mode == V8HImode)"
"vaddu<VI_char>m %0,%1,%2"
[(set_attr "type" "vecsimple")])
Then we can move vsx_add<mode>3 to vsx.md, but that is still messy.
Another way to do this is to use the ISA alternatives. Something like
(note, the iterator names can be changed, I'm just trying to be more
obvious about the modes). Two of the vector modes won't have FUTURE
versions, and 2 do, so you split the add into separate insns that don't
have to worry about FUTURE and those that do:
(define_mode_iterator V16QI_V8HI [V16QImode V8HImode])
(define_mode_iterator V4SI_V2DI [V4SImode V2DImode])
(define_insn "add<mode>3"
[(set (match_operand:V16QI_V8HI 0 "register_operand" "=v")
(plus:V16QI_V8HI (match_operand:V16QI_V8HI 1 "register_operand" "v")
(match_operand:V16QI_V8HI 2 "register_operand" "v")))]
"<VI_unit>"
"vaddu<VI_char>m %0,%1,%2"
[(set_attr "type" "vecsimple")])
(define_insn "add<mode>3"
[(set (match_operand:V4SI_V2DI 0 "register_operand" "=v,wa")
(plus:V4SI_V2DI (match_operand:V4SI_V2DI 1 "register_operand" "v,wa")
(match_operand:V4SI_V2DI 2 "register_operand" "v,wa")))]
"<VI_unit>"
"@
vaddu<VI_char>m %0,%1,%2
xvaddu<VI_char>m %x0,%x1,%x2")"
[(set_attr "type" "vecsimple")
(set_attr "isa" "*,future")])
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: [email protected]
