GAS .fpu directive

[Renato Golin]

So,

The fact that:

  .fpu vfpv2
  vabs.f32 s1, s0
  .fpu neon
  vmov d0, d0

sets:

  FP_arch: VFPv3
  Advanced_SIMD_arch: NEONv1

and

  .fpu neon
  vmov d0, d0
  .fpu vfpv2
  vabs.f32 s1, s0

sets:

  FP_arch: VFPv2
  Advanced_SIMD_arch: NEONv1

tells me that:

1. Neon flags sets vfp3, but vfp2 flags don't unset NEON (which is kind of ok).

2. The last flag seen is what goes in the "module context" (aka build
attributes), and that's wrong

3. It's not possible, in ARM, to unset an .fpu/.cpu etc, making their
usage in .text dangerous (leaking assumptions)

4. Merging assembly files, inline assembly or partially linking files
may make the in-text-fpu setting very complicated to deal with

So, my proposal is to tackle one problem at a time:

Problem A:

Regarding module context (build attributes in ARM speak), command line
options should override header options (before .text or any
instruction or non-header directive). Non-header options should have
no change in module context.

So...

$ echo ".cpu cortex-a8" | as -mcpu=arm11

should produce ARM11 as CPU type.

$ echo ".fpu neon\n .text\n .fpu vfpv2" | as

should produce NEON+VFP3 as FPU/NEON types

Problem B:

Local fpu/cpu/arch options are undefined and will have rest-of-the
file context. It's up to the user to make sure they're right.

There are some ways of fixing this:

1. Create a push/pop semantics, like Power. That's probably unlikely
for ARM, but would be the best to have.

2. Define that those directives have function/section scope, so reset
to the module level value on next function definition/section.

3. Leave as is, but add .fpu/.cpu at the end of inline assembly blocks
with the global value to reset expected behaviour. Hand assembly would
still be at peril.


We can solve A before B. Does that make sense?

cheers,
--renato