This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][ARM] FAIL: gcc.target/arm/pr58041.c scan-assembler ldrb
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Richard Earnshaw <rearnsha at arm dot com>
- Cc: Kyrylo Tkachov <Kyrylo dot Tkachov at arm dot com>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, Julian Brown <julian at codesourcery dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 30 May 2014 00:19:24 +0100
- Subject: Re: [PATCH][ARM] FAIL: gcc.target/arm/pr58041.c scan-assembler ldrb
- Authentication-results: sourceware.org; auth=none
- References: <20130809110108 dot 4b63b456 at octopus> <5204CB97 dot 6050205 at arm dot com> <alpine dot DEB dot 1 dot 10 dot 1405260424161 dot 512 at tp dot orcam dot me dot uk> <CAJA7tRZ_wmKGJpDs2DvAgKEP8FkWfPZw+jAfSbTqXDW16vckMA at mail dot gmail dot com> <5384AE58 dot 4050001 at arm dot com> <alpine dot DEB dot 1 dot 10 dot 1405271908140 dot 512 at tp dot orcam dot me dot uk> <53859E94 dot 4080906 at arm dot com>
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.
Maciej