[arm][patch] fix arm_neon_ok check on !arm_arch7

[Andrew Stubbs]

Ping.

On 23/12/14 16:46, Andrew Stubbs wrote:
> On 03/12/14 15:03, Andrew Stubbs wrote:
>>> The tools have always allowed us to drop down the arch to
>>> march=armv5te along with using -mfpu=neon. We are now changing command
>>> line behaviour, so an inform in terms of diagnostics to the user would
>>> be useful as it states that we don't really have mfpu=neon generating
>>> neon code any more because of this particular case. If we are to do
>>> this then the original patch is probably not enough as it then doesn't
>>> handle the case of TARGET_VFP3 / TARGET_VFP5 / TARGET_NEON_FP16 /
>>> TARGET_FP16 / TARGET_FPU_ARMV8 etc. etc. etc.
>>
>> I'll take a look at those shortly.
>
> Or, not so shortly.
>
> It seems that, on ARM, the arch/CPU setting is basically orthogonal to
> the FPU setting, and the compiler doesn't even try to match the one to
> the other. The assembler does the same. In fact, the testcases that
> James refers to, that have hard-coded -march options, really do emit
> armv4 code with Neon, say, although most probably don't have
> vectorizable code. They only work because they're most likely executed
> on Neon hardware.
>
> This means that there's no obvious patch to fix the issue, in the
> compiler. It's easy to reject Neon for pre-v7 CPUs, but that has
> consequences, as we've seen. We'd have to have a table of fall-back FPUs
> or something, and that doesn't seem straight-forward (and anyway, I'm
> not sure what values to enter into that table).
>
> So, I've attacked the problem from the other end, and updated the
> compiler check.
>
> OK to commit?
>
> Andrew