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.