RE: [PATCH]middle-end Use subregs to expand COMPLEX_EXPR to set the lowpart.

[Tamar Christina <Tamar.Christina@arm.com>]

> -----Original Message-----
> From: Gcc-patches <gcc-patches-
> bounces+tamar.christina=arm.com@gcc.gnu.org> On Behalf Of Jeff Law via
> Gcc-patches
> Sent: Sunday, June 12, 2022 6:27 PM
> To: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH]middle-end Use subregs to expand COMPLEX_EXPR to
> set the lowpart.
> 
> 
> 
> On 6/9/2022 1:52 AM, Tamar Christina via Gcc-patches wrote:
> > Hi All,
> >
> > When lowering COMPLEX_EXPR we currently emit two VEC_EXTRACTs.
> One
> > for the lowpart and one for the highpart.
> >
> > The problem with this is that in RTL the lvalue of the RTX is the only
> > thing tying the two instructions together.
> >
> > This means that e.g. combine is unable to try to combine the two
> > instructions for setting the lowpart and highpart.
> >
> > For ISAs that have bit extract instructions we can eliminate one of
> > the extracts if, and only if we're setting the entire complex number.
> >
> > This change changes the expand code when we're setting the entire
> > complex number to generate a subreg for the lowpart instead of a
> vec_extract.
> >
> > This allows us to optimize sequences such as:
> Just a note.  I regularly see subregs significantly interfere with optimization,
> particularly register allocation.  So be aware that subregs can often get in the
> way of generating good code.  When changing something to use subregs I
> like to run real benchmarks rather than working with code snippets.
> 
> 
> >
> > _Complex int f(int a, int b) {
> >      _Complex int t = a + b * 1i;
> >      return t;
> > }
> >
> > from:
> >
> > f:
> > 	bfi     x2, x0, 0, 32
> > 	bfi     x2, x1, 32, 32
> > 	mov     x0, x2
> > 	ret
> >
> > into:
> >
> > f:
> > 	bfi	x0, x1, 32, 32
> > 	ret
> >
> > I have also confirmed the codegen for x86_64 did not change.
> >
> > Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu
> > and no issues.
> >
> > Ok for master?
> >
> > Thanks,
> > Tamar
> >
> > gcc/ChangeLog:
> >
> > 	* emit-rtl.cc (validate_subreg): Accept subregs of complex modes.
> > 	* expr.cc (emit_move_complex_parts): Emit subreg of lowpart if
> possible.
> >
> > gcc/testsuite/ChangeLog:
> >
> > 	* g++.target/aarch64/complex-init.C: New test.
> OK.
> 
> On a related topic, any thoughts on keeping complex objects as complex
> types/modes through gimple and into at least parts of the RTL pipeline?
> 
> The way complex arithmetic instructions work on our chip is going to be
> extremely tough to utilize in GCC -- we really need to the complex
> types/arithmetic up through RTL generation at the least. Ideally we'd even
> expose complex modes all the way to final.    Is that something y'all could
> benefit from as well?  Have y'all poked at this problem at all?

Not extensively, but right now the big advantage of lowering them early is for
auto-vec.   Lowering them early allows you to e.g. realize that you only need the
imaginary part of the number etc.  For auto-vec it also means we treat them as
just any other loads/stores.

I think LLVM keeps them as complex expressions much longer and they've been
having a harder time implementing some of the complex arith stuff we did in GCC 11.

Regards,
Tamar

> 
> jeff