This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][ARM] FAIL: scan-assembler ldrb

On Wed, 28 May 2014, Richard Earnshaw wrote:

> Ah, light dawns (maybe).
> I guess the problems stem from the attempts to combine Neon with ARMv5.
>  Neon shouldn't be used with anything prior to ARMv7, since that's the
> earliest version of the architecture that can support it.

 Good to know, thanks for the hint.  Anyway it's the test case doing 
something silly or maybe just odd.  After all IIUC ARMv5 code will run 
just fine on ARMv7/NEON hardware so mixing up ARMv5 scalar code with NEON 
vector code is nothing wrong per se.

> I guess that what is happening is that we see we have Neon, so start to
> generate a Neon-based copy sequence, but then notice that we don't have
> misaligned access (something that must exist if we have Neon) and
> generate VLDR instructions in a mistaken attempt to work around the
> first inconsistency.
> Maybe we should tie -mfpu=neon to having at least ARMv7 (though ARMv6
> also has misaligned access support).

 So to move away from the odd mixture of instruction selection options 
just as a quick test I rebuilt the same file with `-march=armv7-a 
-mno-unaligned-access' and the result is the same, a pair of VLDR 
instructions accessing unaligned memory, i.e. the same problem.

 So based on observations made so far I think there are two sensible 
ways to move forward:

1. Fix GCC so that a manual byte-wise copy is made whenever 
  `-mno-unaligned-access' is in effect.

2. Revert the change being discussed here as its lone purpose was to 
   disable the use of VLD1.8, etc. where `-mno-unaligned-access' is in 
   effect, and it does no good.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]