Integrated ARM assembler

Project Infrastructure LLVM Dev List Archives
#1

Hi all,

I remember the discussion about promoting the integrated ARM assembler as the default option, but I don’t remember the outcome.

While compiling on ARM, I noticed that clang is not setting the integrated-as by default and is calling GAS before LD, which sometimes cause confusion (GAS doesn’t like using r13 as a GPR, for instance).

While this is unpredictable in Thumb, it’s still allowed in ARM mode (though frowned upon). But aside from discussing the SP issue, is there anything holding the integrated assembler back from being on by default?

cheers,
–renato

#2

Hi Renato,

is there anything holding the integrated assembler back from being on by default?

For ARM-ELF, a couple missing pieces I see:

  1. The assembly parser does not parse the ARM-ELF directives.

  2. The Exception Handling ABI does not appear to be supported. Try this:

$ echo “void a(){}” | clang -target arm-none-linux-gnueabi -mllvm -arm-enable-ehabi -integrated-as -c -xc -
Not implemented yet

  1. There are -Wa options that the integrated assembler does not recognize.

To reproduce these issues, try building chromium targeting Android with “clang=1” after adding ‘-integrated-as’ to cflags in “build/common.gypi”.

http://code.google.com/p/chromium/wiki/Clang

-Greg

#3

Hi Greg,

#4

Hi Greg,

I'd also like to see the integrated assembler enabled, though I'm only
very weakly connected to the 32-bit backend.

1) The assembly parser does not parse the ARM-ELF directives.

Renato asked about inline assembly here, but I think the key question
is over the directives LLVM itself decides to generate as a result of
Clang invocations. I had a very brief encounter last year which
suggested this path was in place.

Is there anything you're aware of that's missing along that route? If
there is, I think there's a good chance we can invest some time in
fixing it.

In general terms, I'd like to see integrated-as enabled as soon as it
reasonably can be. Relying on gas is icky. Does anyone know of actual
clang regressions that would be triggered?

Cheers.

Tim

#5

The assembly parser does not parse the ARM-ELF directives.

Is this for inline asm?

Yep

$ echo “void a(){}” | clang -target arm-none-linux-gnueabi -mllvm -arm-enable-ehabi -integrated-as -c -xc -
Not implemented yet
Seems to work for me… :wink:

I see this just recently changed. I just confirmed the issue is in the ‘release_32’ branch, but not in ‘master’.

There are -Wa options that the integrated assembler does not recognize.
That’s not really a problem and will always be that way.

What I’d prefer to see is if the integrated-as doesn’t recognize the option, clang should report a warning and switch to the ‘no-integrated-as’ path. Thoughts?

I think the key question is over the directives LLVM itself decides to generate as a result of
Clang invocations

I agree that’s the more important question, but shouldn’t we be able to throw hand-written assembly files at clang too?

It’d be nice to assert that clang can consume its own generated assembly. Check this out (for brevity, assumes arm target is the default):

$ echo “void a(){}” | clang -x c -S - -o - | clang -x assembler -c - -integrated-as
:2:2: error: unknown directive
.eabi_attribute 6, 2

Does anyone know of actual clang regressions that would be triggered?

I haven’t seen any serious issues. Just little things like getting “unsupported argument” if you throw it: “-Wa,-mimplicit-it=always”.

I’d like to see integrated-as enabled as soon as it reasonably can be

I agree, but if you do it today, some builds will certainly choke at compile-time. Chromium serves as a nice big workload that currently builds with a very recent version of Clang. As is, that build will go down if you switched the default on them.

Thanks,
Greg

#6

> Is this for inline asm?

Yep

In that case, using GAS is always a better options... for now. :wink:

What I'd prefer to see is if the integrated-as doesn't recognize the

option, clang should report a warning and switch to the 'no-integrated-as'
path. Thoughts?

The main problem with this is that in a large project, with different
flags, some files will be compiled with integrated-as, others with GAS, and
this could also change in time, creating a good headache for many people. :wink:

I agree that's the more important question, but shouldn't we be able to

throw hand-written assembly files at clang too?

Of course we should, but as long as it's hidden behind a flag, it'll never
be properly tested and people will never fix the bugs...

$ echo "void a(){}" | clang -x c -S - -o - | clang -x assembler -c -

-integrated-as
<stdin>:2:2: error: unknown directive
.eabi_attribute 6, 2

Hum, that's bad and should be fixed. Can you create a bug, pls?

I agree, but if you do it today, some builds will certainly choke at

compile-time. Chromium serves as a nice big workload that currently builds
with a very recent version of Clang. As is, that build will go down if you
switched the default on them.

I think this is a concern. Not everyone can change to recent versions of
clang as soon as they come out, but as long as the problems are just
warnings, I think we can risk a bit more exposure.

Can you compile Chromium entirely, ignoring the warnings and hand-written
ASM, with integrated-as, for ARM?

In your project configuration, you could add "-no-integrated-as" for the
parts that do have inline ASM.

cheers,
--renato

#7

Hum, that’s bad and should be fixed. Can you create a bug, pls?

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

In that case, using GAS is always a better options… for now. :wink:

I think we are very close to fully supporting inline ARM assembly, no? Just need to parse those few ELF-specific directives?

The main problem with this is that in a large project, with different flags, some files
will be compiled with integrated-as, others with GAS, and this could also change
in time, creating a good headache for many people. :wink:

So I think our options are:

  1. warn & use GAS if option is missing. Renato gives -1.
  2. warn that we are ignoring these unsupported options.
  3. block integrated-as default until GAS options are implemented.
  4. turn on integrated-as by default, leave the error, and expect users to workaround. Greg gives -1.

-Greg