On Fri, 2010-12-03 at 10:49 +1300, Michael Hope wrote:
> Hi there. Currently you can't use NEON instructions in inline
> assembly if the compiler is set to -mfpu=vfp such as Ubuntu's
> -mfpu=vfpv3-d16. Trying code like this:
>
> int main()
> {
> asm("veor d1, d2, d3");
> return 0;
> }
>
> gives an error message like:
>
> test.s: Assembler messages:
> test.s:29: Error: selected processor does not support Thumb mode `veor
> d1,d2,d3'
>
> The problem is that -mfpu=vfpv3-d16 has two jobs: it tells the
> compiler what instructions to use, and also tells the assembler what
> instructions are valid. We might want the compiler to use the VFP for
> compatibility or power reasons, but still be able to use NEON
> instructions in inline assembler without passing extra flags.
Sorry, I disagree with that distinction.
>
> Inserting ".fpu neon" to the start of the inline assembly fixes the
> problem. Is this valid?
Not really. It changes the global setting for the rest of the file and
changes the global attributes on your object.
> Are assembly files with multiple .fpu
> statements allowed? Passing '-Wa,-mfpu=neon' to GCC doesn't work as
> gas seems to ignore the second -mfpu.
>
> What's the best way to handle this? Some options are:
> * Add '.fpu neon' directives to the start of any inline assembly
Nope, .fpu neon is used in building the attributes data. The attribute
architecture in the ABI supports attributes on sections or symbols, it
does not support them on arbitrary snippets of code. The point of
attributes is to reason about compatibility and users intentions. You
can't do that if the attributes data is messed up.
Currently BFD/GAS/GOLD cannot generate/interpret attributes on
sub-elements of object files; they can only work on file-scope
attributes. That's a bug, but it's not really relevant to this
discussion.
> * Separate out the features, so you can specify the capabilities with
> one option and restrict the compiler to a subset with another.
> Something like '-mfpu=neon -mfpu-tune=vfpv3-d16'
That'll just confuse users, IMO. Also, see below
> * Relax the assembler so that any instructions are accepted. We'd
> lose some checking of GCC's output though.
Trust me, you just don't want to do that (see above).
You've missed the right answer though: make the compiler smarter. The
compiler should be able to work out when it's beneficial to use neon and
when it's not: adding hooks to try and defeat a poor choice by the
compiler sounds like bad design to me.
R.
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
