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
