Thanks for the Approval Michael! Can i backport this patch to gcc-16?
~Kishan On 07/07/26 12:18 am, Michael Meissner wrote: > 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. >
