https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989
--- Comment #12 from Wilco <wilco at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #11) > From my completely ARM unaware POV, if NEON is available, it isn't a strict > requirement that NEON must never be used for this, just a matter of > preferences. So perhaps one or two further ?s on the avoid_neon_for_64bits > alternatives to let the RA know it should prefer the GPR alternative which > already contains a single ? and therefore right now is equal preference to > the avoid_neon_for_64bits. The costing model for preferencing is extremely complex and suboptimal. There are too many bugs in it, it all appears to be written for a CISC ISA (eg. it assumes it can just replace any register operand with a MEM at no extra cost, even if such a pattern doesn't exist). So hacking in some more ?'s is never going to result in good code. The issue is also made more complex by the fact that expanding 64-bit operations after register allocation is an extremely bad idea - see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308. So today the choice is between generating inefficient ARM code or inefficient Neon code... By making this a hard choice early on (only generate ARM, or use Neon when beneficial) we can actually generate high quality code. I've got patches that give huge gains and still allow a user to prefer Neon instructions with -mneon-for-64bits.
