Hi Richard B., Many thanks. I'll plan to push this on Friday evening. As with any change, if there are any issues, once identified, the bugs can be fixed or the patch reverted.
Any chance that I could also ask to you to provisionally approve: https://gcc.gnu.org/pipermail/gcc-patches/2026-July/722363.html It's a related change (that explicitly checks/handles endianness). If there are no objections, I can plan to push this on Friday too, and combine the post-commit bootstraps and regression tests over the weekend. Thanks again, and thanks in advance, Roger -- > -----Original Message----- > From: Richard Biener <[email protected]> > Sent: 08 July 2026 12:18 > To: Roger Sayle <[email protected]> > Cc: GCC Patches <[email protected]> > Subject: Re: [PATCH] PR target/99668: Improved complex to vector RTL > expansion. > > On Tue, Jul 7, 2026 at 4:36 PM Roger Sayle <[email protected]> > wrote: > > > > > > Hi Richard, > > Thanks for the review. Here's a revised patch incorporating your feedback. > > I'd considered arguing that none of the other callers of > > vec_init_optab in the middle-end currently allow it to FAIL, but with > > the factorization into a helper function (so that icode doesn’t have > > to be looked up twice), it's trivially easy to handle it here (and > > perhaps update the other callers in future). > > Yeah, it might be a documentation omission but I didn't check whether any > targets vec_init can actually fail. > > > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap > > and make -k check, both with and without --target_board=unix{-m32} > > with no new failures. Ok for mainline? > > LGTM, I'm always a bit nervous with endianess issues, but I _think_ you got > that > correct. Please wait a day or two so anybody else can double-check that. > > Thanks, > Richard. > > > 2026-07-07 Roger Sayle <[email protected]> > > Richard Biener <[email protected]> > > > > gcc/ChangeLog > > PR target/99668 > > * expr.cc (try_expand_complex_as_vector): Try to use vec_init_optab > > to convert a complex number to a two-component vector with the same > > inner type. > > (expand_expr_real_1) <case VIEW_CONVERT_EXPR>: Check whether the > > above function can be used to implement this VIEW_CONVERT_EXPR. > > > > gcc/testsuite/ChangeLog > > PR target/99668 > > * gcc.target/i386/pr99668.c: New test case. > > > > > > Thanks again, > > Roger > > -- > > > -----Original Message----- > > > From: Richard Biener <[email protected]> > > > Sent: 01 July 2026 08:25 > > > To: Roger Sayle <[email protected]> > > > Cc: GCC Patches <[email protected]> > > > Subject: Re: [PATCH] PR target/99668: Improved complex to vector RTL > > > expansion. > > > > > > On Tue, Jun 30, 2026 at 11:42 PM Roger Sayle > > > <[email protected]> > > > wrote: > > > > > > > > > > > > This patch improves the RTL expansion of casts (VIEW_CONVERT_EXPR) > > > > from complex numbers to two-component vectors with the same inner > > > > type. Currently, expand spills the complex number to memory to > > > > perform this conversion. With the patch below we now convert the > > > > V_C_E into the equivalent of (v2x){__real__ z,__imag__ z}, using > > > > the backend's vec_init_optab. > > > > > > > > The motivating example from the Bugzilla PR is: > > > > > > > > typedef double v2df __attribute__((vector_size(16))); v2df foo > > > > (_Complex double x) { > > > > return *(v2df *)&x; > > > > } > > > > > > > > Currently, with -O2 GCC implements this by spilling to memory: > > > > > > > > foo: movsd %xmm0, -24(%rsp) > > > > movsd %xmm1, -16(%rsp) > > > > movupd -24(%rsp), %xmm0 > > > > ret > > > > > > > > with this enhancement to RTL expansion, we now generate: > > > > > > > > foo: unpcklpd %xmm1, %xmm0 > > > > ret > > > > > > > > The improvement with -m32 -msse2 -O2 is even more pronounced. > > > > > > > > From: subl $28, %esp > > > > movsd 32(%esp), %xmm1 > > > > movsd 40(%esp), %xmm2 > > > > movsd %xmm1, (%esp) > > > > movsd %xmm2, 8(%esp) > > > > movupd (%esp), %xmm0 > > > > addl $28, %esp > > > > ret > > > > > > > > To: movq 4(%esp), %xmm0 > > > > movhpd 12(%esp), %xmm0 > > > > ret > > > > > > > > > > > > This patch has been tested on x86_64-pc-linux-gnu with make > > > > bootstrap and make -k check, both with and without > > > > --target_board=unix{-m32} with no new failures. Ok for mainline? > > > > > > I'll note the documentation of vec_init doesn't state the pattern is > > > not allowed to FAIL, so I think you need to handle the expander failing. > > > > > > Also > > > > > > + if (!REG_P (rpart) && !CONSTANT_P (rpart)) > > > + rpart = force_reg (GET_MODE_INNER (mode), rpart); > > > + if (!REG_P (ipart) && !CONSTANT_P (ipart)) > > > > > > I think there's one extra space after part) and it would be nice to > > > do the icode = convert_optab_handler assignment as part of the if () to > > > not > repeat it. > > > > > > Otherwise a good idea. > > > > > > Thanks, > > > Richard. > > > > > > > > > > > > > > > 2026-06-30 Roger Sayle <[email protected]> > > > > > > > > gcc/ChangeLog > > > > PR target/99668 > > > > * expr.cc (expand_expr_real_1) <case VIEW_CONVERT_EXPR>: Use > > > > vec_init_optab to convert a complex number into two-component > > > > vector with the same inner type. > > > > > > > > gcc/testsuite/ChangeLog > > > > PR target/99668 > > > > * gcc.target/pr99668.c: New test case. > > > > > > > > > > > > Thanks in advance, > > > > Roger > > > > -- > > > >
