GAS .fpu directive

GAS .fpu directive

[Renato Golin]

Folks,

We seem to be hitting some bugs on the .fpu directive in ARM assembly
files, and I'd like to ask you guys about a seemingly undocumented
behaviour.

It seems GAS accepts .fpu anywhere in the file, and the meaning is
that it can change the FPU type mid-way through an assembly file, or
even in a block. For example:

  .fpu vfp
  vmov.i64  d0, #0 @ selected FPU does not support instruction
 .fpu neon
  vmov.i64  d0, #1 @ ok
  .fpu vfp
  vmov.i64  d0, #2 @ selected FPU does not support instruction

Is that intentional? Is there any real usage for this kind of thing?

I naively assumed that .cpu / .fpu were like .eabi_attribute flags
that would tell what the *file* is, because normally one assembly
won't run on different machines at the same time.

The only use case I can think of is if there is a conditional jump
based on the existence of instructions, so a block that has neon is
only executed if there's no exception, but that still doesn't need a
.fpu vfp somewhere else.

cheers,
--renato

Re: GAS .fpu directive

[Nicholas Clifton]

Hi Renato,

> It seems GAS accepts .fpu anywhere in the file, and the meaning is
> that it can change the FPU type mid-way through an assembly file, or
> even in a block.

> Is that intentional?

No.

> Is there any real usage for this kind of thing?

Yes.

> I naively assumed that .cpu / .fpu were like .eabi_attribute flags
> that would tell what the *file* is, because normally one assembly
> won't run on different machines at the same time.

Correct.

> The only use case I can think of is if there is a conditional jump
> based on the existence of instructions, so a block that has neon is
> only executed if there's no exception, but that still doesn't need a
> .fpu vfp somewhere else.

Right.  Basically such an sceanario is theoretically possible, but it is 
unlikely that it will ever turn up in real code.  The real reason why 
the directive is accepted anywhere is that it was just too much bother 
to write additional code to make sure that it is only used once, and 
then only in an appropriate place.  Much easier to just let it be 
accepted anywhere and to rely upon the assembler programmer or the 
compiler to only generate one instance of the directive.

Cheers
   Nick

Re: GAS .fpu directive

[Renato Golin]

On 20 August 2014 16:44, Nicholas Clifton <nickc@redhat.com> wrote:
> Right.  Basically such an sceanario is theoretically possible, but it is
> unlikely that it will ever turn up in real code.

Unfortunately, it did.

http://llvm.org/bugs/show_bug.cgi?id=20447

There's also an .arch_extension that has the same semantics, and
Chromium guys are assuming it's intentional because GAS supports it.

I'd really like to add the extra code to make sure we only parse it in
the header and fail if seen anywhere else, and your reply will help me
do it. Can I use it as some sort of "binutils statement" that this
should not happen?


> The real reason why the
> directive is accepted anywhere is that it was just too much bother to write
> additional code to make sure that it is only used once, and then only in an
> appropriate place.  Much easier to just let it be accepted anywhere and to
> rely upon the assembler programmer or the compiler to only generate one
> instance of the directive.

I understand, but people abuse of so many things... Inline asm is
another for of abuse and we've seen so many things that cannot be
unseen... (most LLVMLinux talks/slides will show you some).

Our mission in the LLVM inline assembler is to make those hard
choices, so I'd be glad to be the naughty one to revoke that "feature"
and ask the developer to stop doing that in their sources, if we're in
sync that that's really a bad idea.

For us is just a case of splitting the parseDirective containing a big
switch into two header/body functions, and splitting the parsing into
two loops, so not a big deal.

Thanks,
--renato

Re: GAS .fpu directive

[Peter Bergner]

On Wed, 2014-08-20 at 16:44 +0100, Nicholas Clifton wrote:
> Renato Golin wrote:
> > The only use case I can think of is if there is a conditional jump
> > based on the existence of instructions, so a block that has neon is
> > only executed if there's no exception, but that still doesn't need a
> > .fpu vfp somewhere else.
> 
> Right.  Basically such an sceanario is theoretically possible, but it is 
> unlikely that it will ever turn up in real code.

Is this true for .machine as well?  If so, I know we emit a .machine <cpu>
midway through some glibc code to temporarily modify the .machine value
in as assembler file, before changing it back.  The ugly details are here:

  https://sourceware.org/ml/binutils/2009-01/msg00278.html

As Alan mentions in the follow-up, we ended up using:

 .machine push
 .machine power6
   source that needs power6 insn
 .machine pop

...so there is _some_ use for being able to emit these directives anywhere
in the source file.

Peter

Re: GAS .fpu directive

[Richard Earnshaw]

On 20/08/14 16:44, Nicholas Clifton wrote:
> Hi Renato,
> 
>> It seems GAS accepts .fpu anywhere in the file, and the meaning is
>> that it can change the FPU type mid-way through an assembly file, or
>> even in a block.
> 
>> Is that intentional?
> 
> No.
> 
>> Is there any real usage for this kind of thing?
> 
> Yes.
> 
>> I naively assumed that .cpu / .fpu were like .eabi_attribute flags
>> that would tell what the *file* is, because normally one assembly
>> won't run on different machines at the same time.
> 
> Correct.
> 
>> The only use case I can think of is if there is a conditional jump
>> based on the existence of instructions, so a block that has neon is
>> only executed if there's no exception, but that still doesn't need a
>> .fpu vfp somewhere else.
> 
> Right.  Basically such an sceanario is theoretically possible, but it is 
> unlikely that it will ever turn up in real code.  The real reason why 
> the directive is accepted anywhere is that it was just too much bother 
> to write additional code to make sure that it is only used once, and 
> then only in an appropriate place.  Much easier to just let it be 
> accepted anywhere and to rely upon the assembler programmer or the 
> compiler to only generate one instance of the directive.
> 
> Cheers
>    Nick
> 
> 
> 


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.

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.

R.

Re: GAS .fpu directive

[Renato Golin]

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

Re: GAS .fpu directive

[Peter Bergner]

On Wed, 2014-08-20 at 17:22 +0100, Richard Earnshaw 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.

I also forgot about GCC's function specific optimization support
which would require this:

  https://gcc.gnu.org/wiki/FunctionSpecificOpt

Peter

Re: GAS .fpu directive

[Renato Golin]

On 20 August 2014 17:51, Peter Bergner <bergner@vnet.ibm.com> wrote:
> I also forgot about GCC's function specific optimization support
> which would require this:
>
>   https://gcc.gnu.org/wiki/FunctionSpecificOpt

So, ARCH, CPU and FPU options are not monotonic crescent (ex. this is
not necessarily true in all contexts: a7 < a8 < a9 < a15) and extra
flags (like +neon, +crypto, +d16) make it a multi-axis vector space.
How do you choose the value for the appropriate build attributes in
this case and avoid linking unsupported libraries?

Maybe Intel's cores and SSE/AVX is indeed sequentially linear in
implementation? Does Intel deprecate anything at all?

Anyway, that's probably much more of an ARM problem than a compiler
problem, and that might, indeed, be the reason why I won't be able to
kill that "feature" in LLVM's IAS. Damn! :)

cheers,
--renato

PS: Should this usage and semantics be documented somewhere in
binutils' wiki/docs?

Re: GAS .fpu directive

[Peter Bergner]

On Wed, 2014-08-20 at 19:02 +0100, Renato Golin wrote:
> On 20 August 2014 17:51, Peter Bergner <bergner@vnet.ibm.com> wrote:
> > I also forgot about GCC's function specific optimization support
> > which would require this:
> >
> >   https://gcc.gnu.org/wiki/FunctionSpecificOpt
> 
> So, ARCH, CPU and FPU options are not monotonic crescent (ex. this is
> not necessarily true in all contexts: a7 < a8 < a9 < a15) and extra
> flags (like +neon, +crypto, +d16) make it a multi-axis vector space.
> How do you choose the value for the appropriate build attributes in
> this case and avoid linking unsupported libraries?

Well the common use of the above is to have one library that contains
multiple versions of specific functions optimized for specific cpus.
When someone calls a function say foo(), there would be a IFUNC resolver
that at runtime chooses which optimized version of foo() the user
branches to.  In your case, if you have a function foo() that has been
optimized for a7, a8, a9 and a15, then the resolver could be used to
direct the users call to foo() the the appropriate optimzed version
depending on what cpu their binary happened to be running on.  The IFUNC
resolver could use other criteria other than cpu value if you want.
Maybe code size, or ...



> PS: Should this usage and semantics be documented somewhere in
> binutils' wiki/docs?

The gas docs are here:

  https://sourceware.org/binutils/docs-2.24/as/index.html

The powerpc specific doc for .machine [<cpu>|"push"|"pop"] is here:

  https://sourceware.org/binutils/docs-2.24/as/PowerPC_002dPseudo.html#PowerPC_002dPseudo

Looking at the ARM directives:

  https://sourceware.org/binutils/docs-2.24/as/ARM-Directives.html#ARM-Directives

they don't seem to allow push and pop as values, but they don't preclude
resetting the value somewhere within the assembler file either.

Peter

Re: GAS .fpu directive

[Renato Golin]

On 20 August 2014 20:14, Peter Bergner <bergner@vnet.ibm.com> wrote:
> Looking at the ARM directives:
>
>   https://sourceware.org/binutils/docs-2.24/as/ARM-Directives.html#ARM-Directives
>
> they don't seem to allow push and pop as values, but they don't preclude
> resetting the value somewhere within the assembler file either.

That's the question, should we be explicit about this intention, maybe
hinting about IFUNC?

cheers,
--renato

RE: GAS .fpu directive

[Matthew Fortune]

Renato Golin <renato.golin@linaro.org> writes:
> On 20 August 2014 20:14, Peter Bergner <bergner@vnet.ibm.com> wrote:
> > Looking at the ARM directives:
> >
> >   https://sourceware.org/binutils/docs-2.24/as/ARM-Directives.html#ARM-
> Directives
> >
> > they don't seem to allow push and pop as values, but they don't preclude
> > resetting the value somewhere within the assembler file either.
> 
> That's the question, should we be explicit about this intention, maybe
> hinting about IFUNC?

In case it is of interest... The MIPS assembler has the concept of a file
level setting and then region level settings. This pre-dates ifunc but
one important use of region level settings is ifunc. Such regions do not
have any impact on how the overall module is annotated. The true reason
for the feature appears to be that programmers generally need get-out
clauses in case they need to violate the normal rules. I.e. we shouldn't
presume to know or enforce exactly how an assembler is used but that doesn’t
mean it has to be easy to get non-standard behaviour.

In recent work for MIPS I split the directives into a '.set' which is
(almost) exclusively region specific and '.module' which is module specific
and cannot be used once a code or data directive has been seen.

I guess the question for ARM is whether the .fpu directive changes the
annotation on the object file and if it does, does it do it every time it
is seen or just the first time. If it changes the overall module each time
then that sounds like a source of weird and had-to-find problems.

Hope that is useful.

Thanks,
Matthew

Re: GAS .fpu directive

[Renato Golin]

On 21 August 2014 08:32, Matthew Fortune <Matthew.Fortune@imgtec.com> wrote:
> I guess the question for ARM is whether the .fpu directive changes the
> annotation on the object file and if it does, does it do it every time it
> is seen or just the first time. If it changes the overall module each time
> then that sounds like a source of weird and had-to-find problems.

As far as I understand, .fpu and .cpu are GNU extensions that end up
setting the build attributes in the final object file, which in turn
lets the linker knows what kind of libraries it should link against.
This is not like IFUNC, but it's more of a "give the the most
optimized libraries you have for my particular target" and also "don't
let me shoot my own foot and accidentally compile different object
files with the wrong flags".

So, in both these cases, GAS sets FP_arch = VFPv2:

  .fpu vfpv2
  vabs.f32 s1, s0
  .fpu vfp
  faddd d1, d0, d0

  .fpu vfp
  faddd d1, d0, d0
 .fpu vfpv2
  vabs.f32 s1, s0

In that first case above, LLVM is even worse and sets the last before
even parsing vabs, so it fails with "vabs requires vfp2".

I don't know what the best behaviour is, but if I had to guess, I'd
say either the first (which is more likely to be in the file header)
or the most general (for ex. vfpv3 trumps vfp, but that has corner
cases), or the one that we specifically detected to be in the header
(before any instruction), if any.

cheers,
--renato

RE: GAS .fpu directive

[Matthew Fortune]

Renato Golin <renato.golin@linaro.org> writes:
> On 21 August 2014 08:32, Matthew Fortune <Matthew.Fortune@imgtec.com>
> wrote:
> > I guess the question for ARM is whether the .fpu directive changes the
> > annotation on the object file and if it does, does it do it every time
> it
> > is seen or just the first time. If it changes the overall module each
> time
> > then that sounds like a source of weird and had-to-find problems.
> 
> As far as I understand, .fpu and .cpu are GNU extensions that end up
> setting the build attributes in the final object file, which in turn
> lets the linker knows what kind of libraries it should link against.
> This is not like IFUNC, but it's more of a "give the the most
> optimized libraries you have for my particular target" and also "don't
> let me shoot my own foot and accidentally compile different object
> files with the wrong flags".
> 
> So, in both these cases, GAS sets FP_arch = VFPv2:
> 
>   .fpu vfpv2
>   vabs.f32 s1, s0
>   .fpu vfp
>   faddd d1, d0, d0
> 
>   .fpu vfp
>   faddd d1, d0, d0
>  .fpu vfpv2
>   vabs.f32 s1, s0
> 
> In that first case above, LLVM is even worse and sets the last before
> even parsing vabs, so it fails with "vabs requires vfp2".
> 
> I don't know what the best behaviour is, but if I had to guess, I'd
> say either the first (which is more likely to be in the file header)
> or the most general (for ex. vfpv3 trumps vfp, but that has corner
> cases), or the one that we specifically detected to be in the header
> (before any instruction), if any.

FWIW given that behaviour my suggestion would be that for .fpu you would
want to enforce just one .fpu directive and that should precede all code.
I guess that might break some existing code though but I'd say that is a
good thing.

Introducing a new directive to select the 'current' fpu may then be
necessary for some use cases though. The current situation doesn't sound
good from a hand-coded assembler nor compiler perspective. It seems fairly
undesirable to allow an inline asm block to affect a module's attributes.
It seems less likely to occur in hand-written assembler but the results
would be equally confusing if multiple .fpu directives did appear.

Regards,
Matthew

Re: GAS .fpu directive

[Renato Golin]

On 21 August 2014 10:02, Matthew Fortune <Matthew.Fortune@imgtec.com> wrote:
> FWIW given that behaviour my suggestion would be that for .fpu you would
> want to enforce just one .fpu directive and that should precede all code.
> I guess that might break some existing code though but I'd say that is a
> good thing.

That was my original proposal, and one that I'm ready to enforce in
LLVM's ARM assembler as soon as we reach consensus. :)



> Introducing a new directive to select the 'current' fpu may then be
> necessary for some use cases though. The current situation doesn't sound
> good from a hand-coded assembler nor compiler perspective. It seems fairly
> undesirable to allow an inline asm block to affect a module's attributes.

Indeed!

Other directives have the same problem: .cpu, .arch, .arch_extension,
.eabi_attribute, .syntax, etc.


> It seems less likely to occur in hand-written assembler but the results
> would be equally confusing if multiple .fpu directives did appear.

It does, and that's why I started this discussion. This has shown up
while compiling Chromium for Android with LLVM.

http://llvm.org/bugs/show_bug.cgi?id=20447

cheers,
--renato

Re: 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

Re: GAS .fpu directive

[Will Newton]

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

Re: GAS .fpu directive

[Renato Golin]

On 26 August 2014 10:13, Will Newton <will.newton@linaro.org> wrote:
>> $ 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.

I'm ok with the flags overriding the command line, if that's the
current understanding, but there must be a clear winner. If that's the
flag, so be it.


> 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. ;-)

I understand that GNU tools are generally a lot more forgiving than
LLVM based ones, but there are some things that don't make sense.

This is not the first example that we found where GNU tools are not
clear on what the implementation had to be in the first place, which
allowed developers to rely on nonsensical behaviour. But after a whole
year interacting with those communities (kernel, android, chromium),
there were only a very limited number of times (<1%) where the code
was correct (in all senses). Most of the time it was the wrong
solution in the wrong place, abusing of a broken behaviour from tools
because "it just worked".

Nowadays, whenever someone opens a bug with the text "Clang fails to
support X, like GCC/GAS/LD", I tend to assume the code is wrong, that
the tool mentioned is lax and that the developer is lazy enough to not
check the standards. Which ends up most invariantly true.

Now, there are some reasons to fix existing lax behaviour that people
already use:

1. Maintenance. Can anyone know every possible use of every possible
badly defined behaviour in every possible software out there? Are you
ready to support any two (or more) incompatible relaxed behaviour
across all of GNU tools? Are you actually going to create test cases
to make sure that these unknown uses of your undefined feature is
actually correct? Are you going to document that as the "expected"
behaviour and maintain it as a feature? Isn't the compiler allowed to
change its own undefined behaviour for better code generation?

2. Correctness. This functionality is not just undefined, but it
produces invalid objects and it goes against common sense. If I have
an .fpu on the header and I happen to include another asm file or
inline asm or someone add a .fpu below, it will change the global
state of that object. This will cause all sorts of failures from
(hopefully) compilation time all the way to dynamically linking or
execution. Toolchains should warn about all possible errors that the
user might see, if they can. We can, in this case.

3. Education. This is not just a stick to beat Chromium developers
with, it's a way to make toolchain development sane, too. GCC's errors
and warnings are improving a lot recently, and Clang's diagnosis have
always been great, and my take on this is that we don't want to keep
receiving horrendous bug reports of things that shouldn't even
compile. There are limits and the users will *never* set them, we
must. That's why there are ABIs, standards, committees and user
groups, to define what's sane and what's not and to educate developers
on how to best write their software.

We all know how developers (including myself) have the mentality that
"correct C code" == "gcc compiles", so if the compiler doesn't
complain, it *must* be correct. It then follows that toolchains are,
indeed, educational tools, and it is our responsibility to make sure
it's a good one. For *our* own sake.

cheers,
--renato

Re: GAS .fpu directive

[Renato Golin]

FYI,

http://llvm.org/bugs/show_bug.cgi?id=20757

cheers,
--renato

Re: GAS .fpu directive

[Matt Thomas]

On Aug 21, 2014, at 2:02 AM, Matthew Fortune <Matthew.Fortune@imgtec.com> wrote:

> FWIW given that behaviour my suggestion would be that for .fpu you would
> want to enforce just one .fpu directive and that should precede all code.
> I guess that might break some existing code though but I'd say that is a
> good thing.

I don't know if I can agree with that.

You could have something

.fpu neon
<function neon>

.fpu vfp2
<function vfp2>

and then the caller decides what routine to call depending on the presence
of neon or not (GNU IFUNC per chance).  Same could be said for pre-r6 mips 
code and mipsr6 mips code.  Forcing them to be separate files seems harsh.

I would except the attributes emitted to first match the -mfpu=xxx
option passed to gas, then the first .fpu directive encountered.

Forcing them to be in the "header" makes cpp-processed assembly 
more painful than it should be.

RE: GAS .fpu directive

[Matthew Fortune]

> Same could be said for pre-r6 mips
> code and mipsr6 mips code.  Forcing them to be separate files seems
> harsh.

Thanks to someone in MIPS history, the MIPS assembler pretty much only
modifies an object's attributes based on command line options (and
now a new directive called .module). As such MIPS isn't faced with the
same issue here as it is possible to switch ISAs and operating modes
throughout assembly without impacting the overall object flags.

It's a shame that all the assemblers in binutils are so different
as sharing this kind of feature would give a consistent feel for those
who code for multiple architectures.

Matthew

Re: GAS .fpu directive

[Renato Golin]

On 27 August 2014 01:56, Matt Thomas <matt@3am-software.com> wrote:
> You could have something
>
> .fpu neon
> <function neon>
>
> .fpu vfp2
> <function vfp2>

There is no way of poping context, so the .fpu vfp2 would be valid for
the rest of the file unless you knew what the previous flag was and
added at the end of your sub-context. This is not always possible with
inline asm, or included asm, or even if the compiler is implementing
IFUNC.


> and then the caller decides what routine to call depending on the presence
> of neon or not (GNU IFUNC per chance).  Same could be said for pre-r6 mips
> code and mipsr6 mips code.  Forcing them to be separate files seems harsh.

Between harsh and incorrect, I choose harsh any day.


> I would except the attributes emitted to first match the -mfpu=xxx
> option passed to gas, then the first .fpu directive encountered.

I think we all agree on this one, except when the first .fpu flag is
actually from an overriding snippet, say, an IFUNC implementation,
where you *don't* want that to be the default.


> Forcing them to be in the "header" makes cpp-processed assembly
> more painful than it should be.

The reason why I suggest that is outlined above. Again, better harsh
than incorrect.

cheers,
--renato

Re: GAS .fpu directive

[Richard Earnshaw]

On 27/08/14 17:23, Renato Golin wrote:
> On 27 August 2014 01:56, Matt Thomas <matt@3am-software.com> wrote:
>> You could have something
>>
>> .fpu neon
>> <function neon>
>>
>> .fpu vfp2
>> <function vfp2>
> 
> There is no way of poping context, so the .fpu vfp2 would be valid for
> the rest of the file unless you knew what the previous flag was and
> added at the end of your sub-context. This is not always possible with
> inline asm, or included asm, or even if the compiler is implementing
> IFUNC.
> 
> 
>> and then the caller decides what routine to call depending on the presence
>> of neon or not (GNU IFUNC per chance).  Same could be said for pre-r6 mips
>> code and mipsr6 mips code.  Forcing them to be separate files seems harsh.
> 
> Between harsh and incorrect, I choose harsh any day.
> 

It depends on whether "incorrect" here means "if you don't know what
you're doing you can foul things up; but if you're careful, this is very
powerful", or whether it means, "this is fundamentally broken".

I think someone needs to go away, think about *all* the use cases that
are needed; ponder through how those map on to the assembler directives
and attribute scheme we have (not forgetting that gas/binutils don't use
all of the section/function based attribute features), and comes up with
a way of supporting what's needed.  If that can be done by adjusting the
current scheme, without breaking existing code, then great.  If it means
a migration plan towards a new set of directives, then that's
unfortunate, but at least we should be moving towards something that has
a potential long-term future (we could then leave the existing
directives in place, but deprecate them and gradually migrate over to a
new set that we clearly document).

What I don't want to see is someone tinkering with what is clearly a
fragile API and causing problems for existing toolchains without having
worked through the issues.

I might be able to do some of that thinking, but it's not going to be in
the next few weeks.  Sorry, other things have higher priority.

R.

> 
>> I would except the attributes emitted to first match the -mfpu=xxx
>> option passed to gas, then the first .fpu directive encountered.
> 
> I think we all agree on this one, except when the first .fpu flag is
> actually from an overriding snippet, say, an IFUNC implementation,
> where you *don't* want that to be the default.
> 
> 
>> Forcing them to be in the "header" makes cpp-processed assembly
>> more painful than it should be.
> 
> The reason why I suggest that is outlined above. Again, better harsh
> than incorrect.
> 
> cheers,
> --renato
> 

Re: GAS .fpu directive

[Renato Golin]

On 27 August 2014 17:41, Richard Earnshaw <rearnsha@arm.com> wrote:
> It depends on whether "incorrect" here means "if you don't know what
> you're doing you can foul things up; but if you're careful, this is very
> powerful", or whether it means, "this is fundamentally broken".

The difference between "powerful" and "broken" is if you hit the edge
cases or not. The C++ standard has some clear rules about undefined,
unspecified or implementation defined behaviour, and I believe this
case is of a similar trait. All I'm asking is to acknowledge that this
is undefined and that users should be made aware of the problems, at
least via a warning. In my view, a tool is fundamentally broken if it
allows broken edge cases to pass all checks, and that's exactly what
both assemblers are doing in this case.

The one fundamentally broken issue is the context. It seems that Power
has the ability to push/pop features, which fixes it. We don't. I'm
trying to mitigate the issues by warning the user on dangerous
behaviour, and later on to restrict usage (or at least the context) to
a more sane semantics.

Whether the latter is done or not should not stop the former from
being done. I can't see how a warning on multiple directives would
hurt anything, to be honest.


> What I don't want to see is someone tinkering with what is clearly a
> fragile API and causing problems for existing toolchains without having
> worked through the issues.

That's why I sent the email to the list, to collect ideas and more
edge cases. I've done the homework before contacting the list, but I
can't possibly do that to all architectures on my own, and I'm not
experienced enough to do that comprehensively even for ARM, without
resorting to people like you to validate my findings.

I really appreciate your support and I understand that this is not
high priority.

cheers,
--renato

Re: GAS .fpu directive

[Richard Earnshaw]

On 27/08/14 18:48, Renato Golin wrote:
> On 27 August 2014 17:41, Richard Earnshaw <rearnsha@arm.com> wrote:
>> It depends on whether "incorrect" here means "if you don't know what
>> you're doing you can foul things up; but if you're careful, this is very
>> powerful", or whether it means, "this is fundamentally broken".
> 
> The difference between "powerful" and "broken" is if you hit the edge
> cases or not. The C++ standard has some clear rules about undefined,
> unspecified or implementation defined behaviour, and I believe this
> case is of a similar trait. All I'm asking is to acknowledge that this
> is undefined and that users should be made aware of the problems, at
> least via a warning. In my view, a tool is fundamentally broken if it
> allows broken edge cases to pass all checks, and that's exactly what
> both assemblers are doing in this case.
> 
> The one fundamentally broken issue is the context. It seems that Power
> has the ability to push/pop features, which fixes it. We don't. I'm
> trying to mitigate the issues by warning the user on dangerous
> behaviour, and later on to restrict usage (or at least the context) to
> a more sane semantics.
> 
> Whether the latter is done or not should not stop the former from
> being done. I can't see how a warning on multiple directives would
> hurt anything, to be honest.
> 

Because it's partial at best and some folks like to consider warnings as
fatal.  Consider the use case of

gas -mfpu=neon

then having .fpu vfpv3 inside the code.  Are you going to warn for that
as well?  If not, why not?  But this is a very practical case where the
code has to work and a warning would be incorrect.

Next consider cases where the assembler has built-in defaults.

Finally, there's the case where no instructions are emitted between two
.fpu directives (or code is emitted, but the directive has no effect on
that code).  Are you going to rule that out as well?

As I say, this is all quite complex and making changes without working
through all the use cases is potentially going to cause more problems
than it solves.

R.

> 
>> What I don't want to see is someone tinkering with what is clearly a
>> fragile API and causing problems for existing toolchains without having
>> worked through the issues.
> 
> That's why I sent the email to the list, to collect ideas and more
> edge cases. I've done the homework before contacting the list, but I
> can't possibly do that to all architectures on my own, and I'm not
> experienced enough to do that comprehensively even for ARM, without
> resorting to people like you to validate my findings.
> 
> I really appreciate your support and I understand that this is not
> high priority.
> 
> cheers,
> --renato
> 

Re: GAS .fpu directive

[Renato Golin]

On 28 August 2014 12:05, Richard Earnshaw <rearnsha@arm.com> wrote:
> Because it's partial at best and some folks like to consider warnings as
> fatal.

I'm sure they will be happy to realise they've been doing something
wrong. But that's more of an LLVM opinion than a GNU one, and I
respect that.

That's why, on my latest proposal (http://llvm.org/PR20757), the main
difference here is *only* that "directives in text won't change unit
level attributes". Everything else is optional.



>  Consider the use case of
>
> gas -mfpu=neon
>
> then having .fpu vfpv3 inside the code.  Are you going to warn for that
> as well?  If not, why not?

It depends. Will said the directive overrides the argument, and that
still stands.

The issue here is only between header and text flags. Multiple flags
in the header is also fine, last seen sticks, as is today.

The only difference is that, if a flag is seen in text, it shouldn't
change the global behaviour, only local. This is what's wrong with GAS
right now and should be fixed.


> Next consider cases where the assembler has built-in defaults.

That falls into the same category as compiler flags, since a default
is just an implicit flag.


> Finally, there's the case where no instructions are emitted between two
> .fpu directives (or code is emitted, but the directive has no effect on
> that code).  Are you going to rule that out as well?

If you see my proposal in the bug I created (not my first emails, as
they were uninformed), you'll see that I don't want to remove any
feature nor warn on every potential problem.

1. Header directives shall warn when used in text and *only* change
the behaviour for instruction selection purposes, not for module-wide
properties (like build attributes).

2. If header directives are not present in the header, module-wide
properties will be inferred from the command line, architectural
descriptions, etc. even if they are present in the text.

3. The semantics of directives in text will be that they will change
only the specific behaviour they're related to and they will be valid
until another similar directive is issues or the end of file (compile
unit) is reached.

4. Related flags shall complement each other. So, .cpu cortex-a8 shall
set VFP3 and NEON, while .fpu vfp2 shall only unset VFP3, not NEON and
not move the CPU back to where VFP2 was the default. This is the
current behaviour and shall remain valid.

5. Duplicate header directives in the header generates a *different*
warning, but are accepted on a last come, last served basis. This can
be ignored, or only turned on with -Weverything.

6. Both warnings should become errors when in -Werror mode.

I also don't mention duplicated directives in text because they
shouldn't cause any harm other than setting flags for instructions
selection purposes. So, in the first round of changes, one would still
be able to write:

.cpu cortex-a15
.fpu neon

.text
...
.fpu vfp2 // downgrade vfp, keep neon
...
.fpu vfp3 // upgrade vfp
...
.fpu vfp4 // upgrade vfp again
...

Weather those warnings are enabled with -Wall or -Weverything or
-pedantic is up to the specific assembler. I'd prefer to enable that
by default, you would prefer not, and those are both perfectly valid
choices.

cheers,
--renato

Re: GAS .fpu directive

[Richard Earnshaw]

On 28/08/14 13:07, Renato Golin wrote:
> 4. Related flags shall complement each other. So, .cpu cortex-a8 shall
> set VFP3 and NEON, while .fpu vfp2 shall only unset VFP3, not NEON and
> not move the CPU back to where VFP2 was the default. This is the
> current behaviour and shall remain valid.

Huh?  That's not what gas does today. .cpu must not change the FP
options and .fpu vfpv2 should disable neon if it was previously enabled.

R.

Re: GAS .fpu directive

[Renato Golin]

On 28 August 2014 13:29, Richard Earnshaw <rearnsha@arm.com> wrote:
> Huh?  That's not what gas does today. .cpu must not change the FP
> options and .fpu vfpv2 should disable neon if it was previously enabled.

Huh! You are (obviously) right! I did this test a few days ago and
.fpu vfp2 didn't unset NEON, which was odd. Right now, I did the same
test and voila.

Anyway, what it is is correct, and I'm glad I won't have to change
*that* one, too.

Sorry for the noise.

--renato