[PATCH take #2] x86_64: Improve code expanded for highpart multiplications.
Uros Bizjak
ubizjak@gmail.com
Mon Dec 20 12:44:29 GMT 2021
On Mon, Dec 20, 2021 at 12:26 PM Roger Sayle <roger@nextmovesoftware.com> wrote:
>
>
> Hi Uros,
> Many thanks for the review. Here's a revised patch incorporating your
> suggestion to use a single define_insn with a mode iterator instead of two
> new near identical define_insns for SImode and DImode. I initially tried
> SWI48, but a testsuite failure of pr82418.c revealed that it's more
> efficient on TARGET_64BIT to use a full width multiplication than a
> SImode highpart multiplication, i.e. we only want ?mulsi3_highpart on
> !TARGET_64BIT, so this revised patch uses a DWIH mode iterator.
>
> This patch has been tested on x86_64-pc-linux-gnu by make bootstrap and
> make -k check (with and without RUNTESTFLAGS="--target_board='unix{-m32}'")
> with no new failures. Ok for mainline?
>
>
> 2021-12-20 Roger Sayle <roger@nextmovesoftware.com>
> Uroš Bizjak <ubizjak@gmail.com>
>
> gcc/ChangeLog
> * config/i386/i386.md (any_mul_highpart): New code iterator.
> (sgnprefix, s): Add attribute support for [su]mul_highpart.
> (<s>mul<mode>3_highpart): Delete expander.
> (<s>mul<mode>3_highpart, <s>mulsi32_highpart_zext):
> New define_insn patterns.
> (define_peephole2): Tweak the register allocation for the above
> instructions after reload.
>
> gcc/testsuite/ChangeLog
> * gcc.target/i386/smuldi3_highpart.c: New test case.
OK.
Thanks,
Uros.
>
> Thanks again,
> Roger
> --
>
> > -----Original Message-----
> > From: Uros Bizjak <ubizjak@gmail.com>
> > Sent: 13 December 2021 11:53
> > To: Roger Sayle <roger@nextmovesoftware.com>
> > Cc: GCC Patches <gcc-patches@gcc.gnu.org>
> > Subject: Re: [PATCH] x86_64: Improve code expanded for highpart
> > multiplications.
> >
> > On Fri, Dec 10, 2021 at 12:58 PM Roger Sayle <roger@nextmovesoftware.com>
> > wrote:
> > >
> > >
> > > While working on a middle-end patch to more aggressively use highpart
> > > multiplications on targets that support them, I noticed that the RTL
> > > expanded by the x86 backend interacts poorly with register allocation
> > > leading to suboptimal code.
> > >
> > > For the testcase,
> > > typedef int __attribute ((mode(TI))) ti_t; long foo(long x) {
> > > return ((ti_t)x * 19065) >> 64;
> > > }
> > >
> > > we'd like to avoid:
> > > foo: movq %rdi, %rax
> > > movl $19065, %edx
> > > imulq %rdx
> > > movq %rdx, %rax
> > > ret
> > >
> > > and would prefer:
> > > foo: movl $19065, %eax
> > > imulq %rdi
> > > movq %rdx, %rax
> > > ret
> > >
> > > This patch provides a pair of peephole2 transformations to tweak the
> > > spills generated by reload, and at the same time replaces the current
> > > define_expand with define_insn patterns using the new [su]mul_highpart
> > > RTX codes. I've left the old-style patterns in the machine
> > > description for the time being, but plan to remove these once my
> > > planned middle-end improvements make them obsolete.
> > >
> > > This patch has been tested on x86_64-pc-linux-gnu (both with and
> > > without the middle-end changes) by make bootstrap and make -k check
> > > with no new failures. The new test case, which currently passes,
> > > ensures that the code we generate isn't adversely affected by changes outside
> > the backend.
> > > Ok for mainline?
> > >
> > >
> > > 2021-12-10 Roger Sayle <roger@nextmovesoftware.com>
> > >
> > > gcc/ChangeLog
> > > * config/i386/i386.md (any_mul_highpart): New code iterator.
> > > (sgnprefix, s): Add attribute support for [su]mul_highpart.
> > > (<s>mul<mode>3_highpart): Delete expander.
> > > (<s>muldi3_highpart, <s>mulsi3_highpart, <s>mulsi32_highpart_zext):
> > > New define_insn patterns.
> > > (define_peephole2): Tweak the register allocation for the above
> > > instructions after reload.
> > >
> > > gcc/testsuite/ChangeLog
> > > * gcc.target/i386/smuldi3_highpart.c: New test case.
> >
> > Can you please merge <s>muldi3_highpart and *<s>mulsi3_highpart using
> > SWI48 mode iterator?
> >
> > Uros.
> >
> > >
> > >
> > > Thanks in advance,
> > > Roger
> > > --
> > >
More information about the Gcc-patches
mailing list