Re: GAS .fpu directive

[Will Newton <will dot newton at linaro dot org>]

On 22 August 2014 15:21, Renato Golin <renato.golin@linaro.org> wrote:
> 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.

This is the opposite of what currently happens so I suspect may be a
non-starter from a compatibility standpoint.

> $ 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?

Patches are welcome, but it would be good to be clear on what the
advantages of each individual change are as it is possible people are
relying on various quirks to build their code. I admit the current
status quo doesn't make a whole lot of sense, but I am also reluctant
to make gas into a stick to beat Chromium developers with. ;-)

-- 
Will Newton
Toolchain Working Group, Linaro