On Fri, May 30, 2014 at 12:19 AM, Maciej W. Rozycki <ma...@codesourcery.com> wrote: > 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.
#1 is the preferrable option. > > 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. Reverting this means pr58041 will fail on armv7-a / neon configurations which is what this patch was designed to "fix" ? So it's not an option is it ? Ramana > > Maciej
