ARM Integrated Assembler

Hi Jim/Evan,

We had this discussion last year, and I think it's time we revisited
this issue again.

Many of us (Linaro, ARM, CodeAurora) have been using the ARM
integrated assembler for compiling large projects, the test-suite,
buildbots, and there seem to be no bug pending on them, with the
obscure cases being a few unsupported directives, some of which are
already being implemented, while the rest is reported but not crucial
to fixing it before IAS is default.

The true counter-example is the kernel, which still has many issues,
but I'm not expecting it to support everything in the kernel as of
now. That's why the LLVMLinux guys still use the -no-integrated-as
option by default for both x86 and ARM. Also, their plans is to zero
the patches to the kernel *before* making sure the IAS works
unpatched, which could take a long time.

In a nutshell, it seems to be our consensus that the integrated
assembly can now be turned on by default on ARM, and we should add
-no-integrated-as for the cases where it fails (like the kernel).

Do you agree with this consensus, and does it work as expected on Darwin?

cheers,
--renato

It can't assemble basic PIC code as created by clang -S for ELF
platforms. That's IMO a pretty big show stopper.

Joerg

In a nutshell, it seems to be our consensus that the integrated
assembly can now be turned on by default on ARM, and we should add
-no-integrated-as for the cases where it fails (like the kernel).

I'm definitely in favour!

Tim.

In a nutshell, it seems to be our consensus that the integrated
assembly can now be turned on by default on ARM, and we should add
-no-integrated-as for the cases where it fails (like the kernel).

It can't assemble basic PIC code as created by clang -S for ELF
platforms.

Is there a PR for this? We should link it to one of the issues that
exist for integrated-as.

That's IMO a pretty big show stopper.

I disagree. It's nice and probably should be a priority to fix, but
it's not the standard use-situation for Clang.

Cheers.

Tim.

Without it, -save-temps is broken. As such it falls into a pretty
basic use case.

Joerg

Is there a PR for this? We should link it to one of the issues that
exist for integrated-as.

Or create a new one. If you use "arm integrated assembler" in the
subject line, we can make a filter for all of them.

I disagree. It's nice and probably should be a priority to fix, but
it's not the standard use-situation for Clang.

We have just moved to 3.5svn, and there will be a good number of
months to clear the most egregious bugs in the integrated assembler.
There are also a good number of people working on that right now, so I
don't expect those matters to be forgotten easily.

We tried to do the same last year but there were even more serious
bugs in the IAS. Now, we can run the tests, the test-suite,
benchmarks, large programs (such as Chromium) and so on. It seems to
be the perfect time to not forget about this, but to also have a
smaller number of critical bugs to fix before the next release.

cheers,
--renato

Hi Joerg,

I couldn't find anything in bugzilla that matched your description,
but it seems like a pretty bad problem, can you point us to the
discussion so we can decide whether it should be fixed now, or after
the move.

thanks,
--renato

I haven't created a bug report yet. From memory, the following things
are missing and higher-priority:

Pseudo-ops:
  .abicalls
  .fpu
  .arch
  .cpu

Modifiers:
  foo(GOTOFF)
  foo(GOT)
  foo(PLT)

ldr is a separate issue with a pending patch.

Joerg

I haven't created a bug report yet. From memory, the following things
are missing and higher-priority:

This is looking hopeful.

Pseudo-ops:
        .abicalls

This is MIPS-only.

        .fpu
        .arch
        .cpu

I think there was some opinion that directives like these weren't
essential (well, I certainly hold the opinion!)

Modifiers:
        foo(GOTOFF)
        foo(GOT)
        foo(PLT)

I think David fixed these in r196424.

ldr is a separate issue with a pending patch.

Yep. It'll probably go in in the next few days. Just as soon as we
chain Jim to a computer long enough to give it his blessing.

Cheers.

Tim.

> I haven't created a bug report yet. From memory, the following things
> are missing and higher-priority:

This is looking hopeful.

> Pseudo-ops:
> .abicalls

This is MIPS-only.

Sorry, too much assembler in a short time. You are right.

> .fpu
> .arch
> .cpu

I think there was some opinion that directives like these weren't
essential (well, I certainly hold the opinion!)

At least either .march or .cpu is required for dealing with the infamous
"you have the wrong CPU to use instruction X" issue. I'm not sure about
.fpu yet.

> Modifiers:
> foo(GOTOFF)
> foo(GOT)
> foo(PLT)

I think David fixed these in r196424.

Will test this ASAP.

> ldr is a separate issue with a pending patch.

Yep. It'll probably go in in the next few days. Just as soon as we
chain Jim to a computer long enough to give it his blessing.

:slight_smile:

Joerg

At least either .march or .cpu is required for dealing with the infamous
"you have the wrong CPU to use instruction X" issue. I'm not sure about
.fpu yet.

I think patches for those have already landed upstream...

I think David fixed these in r196424.

Yup.

cheers,
--renato

My bad, they haven't:

http://llvm-reviews.chandlerc.com/D2133

.fpu shouldn't make much difference if the correct build attributes
are there, but AFAIK, LLVM outputs .fpu/.cpu reasonably well (haven't
looked at all the cases), so having .arch should cover all major
problems.

cheers,
--renato

I don't have any real say in this. It should be decided by folks who are working on ARM / ELF such as yourself. If you collectively feel it's ready to make the switch then I don't have any objections.

Evan

Thanks Evan! I wanted to make sure there were no issues on Darwin, as
I really don't get to play much in that area.

I think we have enough interest to change and enough volume of bug
fixes and new features in the IAS to make the move now. I'll send a
patch.

cheers,
--renato

I’m pretty certain that the integrated assembler is already on for darwin/arm.

-Chris

With the recent driver change, I will qualify that as "Clang should be
buildable with -via-file-asm" as criterion for making IAS the default
for a platform. I think that's a reasonable criterion.

Joerg

Ah, in that case, ignore my point. :wink:

Thanks for all your comments, I'll make the changes now and lets see
how things go.

thanks,
--renato

FWIW, I also agree with Joerg that it would be very poor form to turn on -integrated-as when it can’t even eat its own output. This has bitten me before (had to pass -no-integrated-as to reassemble .S output).

I would really like to see it turned on in 3.4 however (just with fixes in place)!

FWIW, I also agree with Joerg that it would be very poor form to turn on
-integrated-as when it can't even eat its own output. This has bitten me
before (had to pass -no-integrated-as to reassemble .S output).

Hi James,

I don't think anyone disagrees with that, and I've been searching for
issues for the past month to make sure no one had any serious
complaints about that.

I've split this into three levels:

1. Dog feeding
2. Critical GNU extensions
3. Oddities

Your concern, and Joergs (and of everyone else for that matter), is
that level one is attained before IAS is on by default. So far, to
everyone that I asked on the list and outside, no one has any
complaints about level one any more. The last two are being reviewed
as we speak and should land in trunk fairly quickly.

The second concern is also being addressed, but the most critical ones
are done already (or being done), and turning the IAS on will help us
identify the missing features. I intend to keep track of those
features and make sure most of them are done by the next release.

For the third class, you can always use -no-integrated-as, or "patches
welcome" (TM).

I would really like to see it turned on in 3.4 however (just with fixes in
place)!

I don't think 3.4 is the right release to do that. Besides, we need to
keep people aware that this has changed (for those tracking trunk,
which seems to be the final consensus on how to track LLVM), so that
they get their own stuff ready before the next release.

I'm aiming to get this out in 3.5, but if there is any horrid bug we
can't fix without a major overhaul, than, well, we wait a bit more.
But I don't think that'll happen.

cheers,
--renato

It just got in on r197052

cheers,
--renato