On Mon, May 11, 2026 at 05:54:31PM +0530, jeevitha wrote:
> Gentle Ping!
> 
> Is it okay for trunk?

Yes, it looks fine.

> Thanks & Regards
> Jeevitha
> 
> 
> On 06/05/26 6:45 pm, jeevitha wrote:
> > Hi All,
> > 
> > The following patch to fix PR122665 has been bootstrapped and regtested
> > on powerpc64-linux-gnu and powerpc64le-linux-gnu with no regressions.
> > 
> > Changes from V2:
> >   * Instead of using unspec, changed to proper smul_highpart and
> >     umul_highpart RTL codes.
> > Changes from V1:
> >   * Moved the unspec declarations from vsx.md to rs6000.md, as these
> >     will be reused in future RFC implementation.
> > 
> > The existing smul<mode>3_highpart and umul<mode>3_highpart patterns
> > incorrectly defined the high-part multiply by shifting both operands
> > right by 32 before multiplication. This does not match the semantics
> > of the instructions vmulhs<wd> and vmulhu<wd>, which perform a widened
> > multiplication and return the high part of the result.
> > 
> > This patch replaces the incorrect shift-based patterns with the proper
> > smul_highpart and umul_highpart RTL codes, and updates the operand
> > predicate from vsx_register_operand to altivec_register_operand, since
> > these instructions only accept Altivec registers.
> > 
> > 2025-05-06  Jeevitha Palanisamy  <[email protected]>
> > 
> > gcc/
> >     PR target/122665
> >     * config/rs6000/vsx.md (smul<mode>3_highpart, umul<mode>3_highpart):
> >     Replace shift-based patterns with smul_highpart and umul_highpart RTL
> >     codes and use altivec_register_operand.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: [email protected]

Reply via email to