Hello Mike, Gentle Ping, to backporting the patch for gcc 16.2. https://patchwork.ozlabs.org/project/gcc/patch/[email protected]/#3717898
Thank You, Kishan On 07/07/26 2:29 pm, Kishan Parmar wrote: > 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. >>
