Hi Jeevitha, Just some minor comments and a general query.
On Wed, 2026-03-25 at 14:23 +0530, jeevitha wrote: > Hi All, > > The following patch is to fix PR122665 has been bootstrapped and > regtested on > powerpc64le-linux. > > Changes from V1: > * Moved the unspec declarations from vsx.md to rs6000.md, as these > will be reused in future RFC implementation. > > rs6000: Fix [su]mul_highpart patterns to use unspec [PR122665] > > The existing smul<mode>3_highpart and umul<mode>3_highpart patterns > incorrectly defined the high-part multiply by shifting both operands > before multiplication. This does not match the semantics of the > instructions vmulhs<wd> and vmulhu<wd>, which perform a widened > multiplication and then return the high part. > > This patch replaces the incorrect patterns with UNSPEC_VMULHS and > UNSPEC_VMULHU forms, and updates the predicate to use > altivec_register_operand, since these instructions accept only > Altivec registers. > > 2025-03-25 Jeevitha Palanisamy <[email protected]> Please update year. > > gcc/ > PR target/122665 > * config/rs6000/rs6000.md (UNSPEC_VMULHS, UNSPEC_VMULHU): > New. New unspec. > * config/rs6000/vsx.md (smul<mode>3_highpart): Use > UNSPEC_VMULHS. > (umul<mode>3_highpart): Use UNSPEC_VMULHU. > > > diff --git a/gcc/config/rs6000/rs6000.md > b/gcc/config/rs6000/rs6000.md > index 3089551552c..a5481df6880 100644 > --- a/gcc/config/rs6000/rs6000.md > +++ b/gcc/config/rs6000/rs6000.md > @@ -173,6 +173,8 @@ > UNSPEC_XXSPLTIW_CONST > UNSPEC_FMAX > UNSPEC_FMIN > + UNSPEC_VMULHS > + UNSPEC_VMULHU > ]) > > ;; > diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md > index cfad9b8c6d5..f4979e447de 100644 > --- a/gcc/config/rs6000/vsx.md > +++ b/gcc/config/rs6000/vsx.md > @@ -6547,25 +6547,19 @@ > (set_attr "size" "<bits>")]) > > (define_insn "smul<mode>3_highpart" > - [(set (match_operand:VIlong 0 "vsx_register_operand" "=v") > - (mult:VIlong (ashiftrt > - (match_operand:VIlong 1 > "vsx_register_operand" "v") > - (const_int 32)) > - (ashiftrt > - (match_operand:VIlong 2 > "vsx_register_operand" "v") > - (const_int 32))))] > + [(set (match_operand:VIlong 0 "altivec_register_operand" "=v") > + (unspec:VIlong [(match_operand:VIlong 1 > "altivec_register_operand" "v") > + (match_operand:VIlong 2 > "altivec_register_operand" "v")] > + UNSPEC_VMULHS))] > "TARGET_POWER10" > "vmulhs<wd> %0,%1,%2" > [(set_attr "type" "veccomplex")]) > > (define_insn "umul<mode>3_highpart" > - [(set (match_operand:VIlong 0 "vsx_register_operand" "=v") > - (us_mult:VIlong (ashiftrt > - (match_operand:VIlong 1 > "vsx_register_operand" "v") > - (const_int 32)) > - (ashiftrt > - (match_operand:VIlong 2 > "vsx_register_operand" "v") > - (const_int 32))))] > + [(set (match_operand:VIlong 0 "altivec_register_operand" "=v") > + (unspec:VIlong [(match_operand:VIlong 1 > "altivec_register_operand" "v") > + (match_operand:VIlong 2 > "altivec_register_operand" "v")] > + UNSPEC_VMULHU))] > "TARGET_POWER10" > "vmulhu<wd> %0,%1,%2" > [(set_attr "type" "veccomplex")]) Just had a query regarding the previous way it was implemented. So for unsigned case in the V4SI mode, (ashiftrt (match_operand:V4SI 1) (const_int 32)) Should have been optimized to 0 right, and therefore fail to generate anything. Does it mean that in backend we do not match such patterns? Thanks and regards, Avinash Jayakar
