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

[Richard Sandiford <richard.sandiford@arm.com>]

Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
> On 6/13/2022 5:54 AM, Richard Biener wrote:
>> On Sun, Jun 12, 2022 at 7:27 PM Jeff Law via Gcc-patches
>> <gcc-patches@gcc.gnu.org> wrote:
>> [...]
>>> 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?
>> Since you are going to need to "recover" complex operations from people
>> open-coding them (both fortran and C and also C++ with std::complex) it
>> should be less work to just do that ;)  I think that complex modes and types
>> exist solely for ABI purposes.
> I don't see any reasonable way to do that.  Without going into all the 
> details, our complex ops work on low elements within a vector 
> register.   Trying to recover them after gimple->rtl expansion would be 
> similar to trying to SLP vectorize on RTL, something I'm not keen to chase.
>
> It would be a hell of a lot easier to leave the complex ops as complex 
> ops to the expanders, then make the decision to use the complex 
> instructions or decompose into components.

Realise you might not be in a position to answer this for confidentiality
reasons, but: would normal tree SLP not help here?  We already try to
recognise complex add & multiply, and in principle we could do the same
for other operations as well.  It shouldn't matter that a vector
multiply on 2 elements is really just a single-data operation.

Thanks,
Richard