On Tue, Jun 23, 2026 at 04:14:54PM +0530, Kishan Parmar wrote:
> Hello,
>
> Below patch is bootstrapped and regtested on powerpc64*-linux-gnu with
> no regressions.
>
> This patch depends on:
> https://www.mail-archive.com/[email protected]/msg407092.html
> for future-vsx stanza support and should be committed after the patch
> is commited.
>
> Changes from v3:
>
> - Tested on both little-endian and big-endian targets.
> - Added documentation and explanatory comments.
> - Reorganized builtins into future-vsx and future-altivec
> stanzas.
> - Fixed mode mismatches in builtin definitions and md patterns
> of altivec_vupkint4tobf16 and altivec_vupkint8tobf16.
> - Updated and corrected testcases as requested during review.
>
> Changes from v2:
> - Add endian compensation sequence for LE so that the logical
> vector element ordering matches BE semantics.
>
> Changes from v1:
> - Add missing author line:
> 2025-03-11 Kishan Parmar <[email protected]>
>
> Thank you,
> Kishan
>
> Add support for vector uncompress and unpack instructions
> proposed in RFC02691. These instructions may or may not be added to a future
> Power processor, and the names of the builtins may change in the future.
>
> The instructions are exposed through new builtins and intrinsics
> interfaces and are enabled when compiling with -mcpu=future.
>
> This patch adds RTL patterns for vector uncompress (nibble, byte, and
> halfword) and unpack operations in altivec.md, along with the
> corresponding builtin definitions in rs6000-builtins.def and overload
> entries in rs6000-overload.def.
This looks ok for the master as it is.
But we may want to dive in to see if we can rewrite the patterns in the
future to describe via RTL what exactly is being done rather than using
an UNSPEC. This might allow the vectorizer to generate these
instructions directly. However, a lot of the instructions are rather
specialized. But we may want to review each one to see if we can
express it.
Consider, vupkint8tofp32. It essentially does:
vector signed char src;
vector float res;
/* Note indexes are adjusted for little endian. */
res[3] = src[12];
res[2] = src[8];
res[1] = src[4];
res[0] = src[0];
Thus you could express vupkint8tofp32 in a little endian system as:
(define_insn "vupkint8tofp32_le"
[(set (match_operand:V4SF 0 "altivec_register_operand" "=v")
(vec_concat:V4SF
(vec_concat:V2SF
(float:SF
(vec_select:SF (match_operand:V16QI 1
"altivec_register_oprand" "v")
(parallel [(const_int 0)])))
(float:SF
(vec_select:SF (match_operand:V16QI 2
"altivec_register_oprand" "v")
(parallel [(const_int 4)]))))
(vec_concat:V2SF
(float:SF
(vec_select:SF (match_operand:V16QI 3
"altivec_register_oprand" "v")
(parallel [(const_int 8)])))
(float:SF
(vec_select:SF (match_operand:V16QI 4
"altivec_register_oprand" "v")
(parallel [(const_int 12)]))))))]
"TARGET_FUTURE && TARGET_LITTLE_ENDIAN && TARGET_ALTIVEC
&& rtx_equal_p (operands[1], operands[2])
&& rtx_equal_p (operands[1], operands[3])
&& rtx_equal_p (operands[1], operands[4])"
"vupkint8tofp32 %0,%1"
[(set_attr "type" "vecsimple")])
Now, perhaps it will match code, perhaps not. It may be an interesting
experiment to try it. Note, we might need to adjust the constants and
the order.
In the past, (match_dup 1) would not work too well before register
allocation (hence all of the match_operands and rtx_equal_p's).
And it would be nice if vec_concat or something similar could take
multiple arguments. Maybe it does now.
If/when the bfloat16 and float16 stuff goes in, we may need to adjust
these patterns to allow those types.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: [email protected]
