This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: GAS .fpu directive
- From: Renato Golin <renato dot golin at linaro dot org>
- To: Richard Earnshaw <rearnsha at arm dot com>
- Cc: Nicholas Clifton <nickc at redhat dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Wed, 20 Aug 2014 17:36:04 +0100
- Subject: Re: GAS .fpu directive
- Authentication-results: sourceware.org; auth=none
- References: <CAMSE1keWd0+uUS0fpaC3-yXsnN-z2_Bsa5anwvQAQwXgWuw_Yw at mail dot gmail dot com> <53F4C261 dot 8090900 at redhat dot com> <53F4CB31 dot 9080701 at arm dot com>
On 20 August 2014 17:22, Richard Earnshaw <rearnsha@arm.com> wrote:
> Actually, I can think of use cases for this 'feature'. Consider a
> function that will only be called when it is known that an ISA extension
> is present (specifically, Neon). We then might want most of the code to
> be marked as no-neon, but then to enable Neon for that function only.
Exactly, and that was my original assumption as to why this is
permitted. But even so, the benefits are limited.
You could say that, by having the rest of the file marked as no-neon,
you'd avoid people adding neon instructions to it. But even marking it
as non-neon, you can't stop people from jumping to a piece of code
where neon is allowed, which has the same effect. Finally, marking the
whole file or just part of it as neon shouldn't change the semantics
to neither the linker (for build attributes' sake) nor the final
executable (if it can never reach a neon instruction).
> I'm not sure that the current implementation really supports that at
> present (it probably ends up setting the attributes incorrectly), but it
> is at least conceivable.
It does. Gas behaves like:
vorr .. @ this is NOT accepted
.fpu neon
vorr .. @ this is accepted
.fpu vfp
vorr .. @ this is NOT accepted
cheers,
--renato