--- Comment #12 from Wilco <wilco at gcc dot> ---
(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

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

Reply via email to