RFC: Promote AArch64 to be built by default

Hi all,

We'd like to promote the AArch64 backend to being built by default. I
know it's very soon after the initial upload, but we think the backend
is in a good position and should be stable.

We'd very much like to get it tested in more diverse environments
provided by the buildbots, and are committed to cleaning up any
fallout as soon as possible, or as a last resort reverting the
"enable" commit.

As before, this doesn't affect our attitude to more reviews: they
would be very welcome.

Does anyone object to me making the necessary changes?

Cheers.

Tim.

I'll own up to suggesting this on IRC. =]

Here is my rationale:
- Tim and others working on the backend have worked with the community for
a while now.
- Tim was particularly diligent in splitting off independent changes, and
all of those are already in place.
- There seems to be broad community support for the backend, so it seems
unlikely to be neglected.

This to me says that the concerns and protections of the experimental
backend aren't needed, and are more likely to impede progress than help it
-- specifically, we won't get good build bot coverage and diverse host
compiler coverage until it's enabled.

My 2-cents.
-Chandler

+1

--renato

Just FYI: the AArch64 tests fail on non-Linux platforms. On my Mac, I get 75 failures running ‘ninja check’, since the tests do not specify a triple and defaults to Darwin, which the backend rejects in createTLOF. I would expect the same behavior on Windows.

Thanks very much, Justin. I'll make sure to resolve these on OSX and
Windows before I flip the switch.

Tim.

I think this is the right thing to do. Once you've resolved the Mac and Windows issues, go for it.

  - Doug

I think this is the right thing to do. Once you've resolved the Mac and Windows issues, go for it.

Thanks Doub. Just to let people know what happened. I enabled in
r174322 around lunchtime. Here's a report of the noticed failures with
status (important/outstanding ones at the top). Feel free to do
anything from telling me about more problems to reverting the patch
when llvm.org comes up.

http://lab.llvm.org:8011/builders/clang-x86_64-ubuntu-gdb-75/builds/1892:
    Didn't rerun configure. If anyone has access to this, forcing it
would be very helpful.
Shared library builds on OSX fail (cyclic dependency):
    I hope to post a patch this evening.
http://lab.llvm.org:8011/builders/clang-x86_64-darwin11-self-mingw32/builds/9058
    There are warnings in AArch64 code. I'll fix them tomorrow. There
may be more warnings not yet noticed, I've been fighting actual
failures today.

The rest are believed resolved:

http://lab.llvm.org:8011/builders/clang-x86_64-darwin11-self-mingw32/builds/9057:
    Improper 33-bit integer constant. Fixed in r174324.
http://bb.pgr.jp/builders/cmake-clang-i686-msvc10/builds/1850
    Improper use of StringRef causing errors when compiler is MSVC
(fixed in r174328)
http://bb.pgr.jp/builders/clang-i686-msys/builds/409:
    llvm-config reported an error, believed to be the result of
incomplete configure step. 410 succeeded.
http://lab.llvm.org:8011/builders/llvm-mips-linux/builds/862:
    Semi-regular timeout?

Cheers.

Tim.

I think this is the right thing to do. Once you've resolved the Mac and Windows issues, go for it.

Thanks Doub. Just to let people know what happened. I enabled in
r174322 around lunchtime. Here's a report of the noticed failures with
status (important/outstanding ones at the top). Feel free to do
anything from telling me about more problems to reverting the patch
when llvm.org comes up.

http://lab.llvm.org:8011/builders/clang-x86_64-ubuntu-gdb-75/builds/1892:
    Didn't rerun configure. If anyone has access to this, forcing it
would be very helpful.

Yeah, not sure what the problem was there - usually the make-based
build reconfigures if it notices changes to the config/source make
files, doesn't it? (or perhaps I'm too used to the cmake build which
certainly does this)

Anyway, I manually nuked the build dir, so hopefully it'll build clean shortly.

http://bb.pgr.jp/builders/cmake-clang-i686-msvc10/builds/1850
    Improper use of StringRef causing errors when compiler is MSVC
(fixed in r174328)

Just a note that I think this is also responsible for:
    http://lab.llvm.org:8011/builders/llvm-x86_64-linux-vg_leak/builds/279

Tim.