Quite surprisingly, this patch increases code size by 3-4% on several SPEC CPU2006 benchmarks for arm-linux-gnueabihf at -Oz optimization level:

1. 473.astar,astar_base.default regressed by 103
2. 450.soplex,soplex_base.default regressed by 103
3. 483.xalancbmk,Xalan_base.default regressed by 104

It's runtime failure and occurs on "ref" input. Compilation flags are
-O3 -marm --target=armv7a-linux-gnueabihf --sysroot=/path/to/build/sysroots/arm-linux-gnueabihf
and linking flags are (note that I'm linking with LLD).
-Wl,--build-id -Wl,-dynamic-linker=/path/to/run/sysroot/lib/ld-2.31.9000.so -Wl,-rpath=/path/to/run/sysroot/lib -Wl,-rpath=/path/to/run/sysroot/usr/lib -O3 -marm --target=armv7a-linux-gnueabihf --sysroot=/path/to/build/sysroots/arm-linux-gnueabihf -fuse-ld=lld

@MaskRay , hi. This patch miscompiles 471.omnetpp and 453.povray on arm-linux-gnueabihf. Would you please investigate?

This commit 4698bf145d583e26ed438026ef7fde031ef322b1

Author: Kazu Hirata <kazu@google.com>
Date: Wed Feb 5 08:24:01 2020 -0800

Hi Nikita,

Hi @kazu ,
This patch increases code-size of 444.namd by 1% on arm-linux-gnueabihf:

• when compiling with -Os: from 171653 to 173645
• when compiling with -Os -flto: from 137772 to 139708

Could you take a look if these regressions can be easily avoided?
Let me know if you need help reproducing the regressions. I have pre-processed source and generated assembly handy.
Thanks!

Hi John,

Looks good.

@leandron , note that you have to commit this patch yourself or (if you don't have commit access) explicitly ask someone here to commit it for you.

Gentle ping? This is a fairly simple patch. Without it I can't enable linaro-armv8-01-arm-libcxx* bots.

Correct patch. First upload had unrelated changes.

Rebase and add -mcpu=cortex-a57 to armv8 32-bit bots.

I'll amend libcxx and global-isel builders per comments in the final commit. Changes for all other bots seem to be OK.

This is being tested on my local buildmaster: http://ex40-01.tcwglab.linaro.org:32775/builders/clang-cmake-armv8-global-isel/builds/

This is a trivial cleanup that was split up from an approved patch: https://reviews.llvm.org/D42039

Rebase on trunk

@gkistanova , would you please merge this before your next planned update to buildmaster? Thanks!

Any yay/nay?

@rovka , slaves linaro-d05-01-* will run in different containers on the same machine (linaro-d05-01). In this context there is no need to repurpose a slave.
I plan to add a second machine linaro-d05-02 that would host the same set of slaves/builders for redundancy.

Rebase after https://reviews.llvm.org/D40607 update

Rebase after https://reviews.llvm.org/D40607 update

In this version jobs= settings are removed (so that they are picked up from slave setting). testsuite_flags are left with 8-thread parallelism for now, and we are going to switch them to 64 once APM hardware is decommissioned.

Would someone with commit access please merge this?

@jgreenhalgh , thanks for the info.

Updated patch with James' comments addressed (testing is still in progress).

In D40423#934358, @jgreenhalgh wrote:

...

So the change makes sense, but the references to Armv8.2-A look wrong to me.

I've successfully tested an earlier version of this patch, but not the uploaded version yet. Please review, but don't submit until testing is finished.

The problem manifests itself in failing "AllocationTests/MappedMemoryTest.***/3" unit-tests when running on ARMv8.2 hardware with linux kernel version ~4.10.

This seems to break armv7: http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/10421 . Any idea on why
FAIL: AddressSanitizer-armhf-linux-dynamic::stack-use-after-return.cc
FAIL: AddressSanitizer-armhf-linux-dynamic::heavy_uar_test.cc
fail?

This seems to break armv7: http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/10421 . Any idea on why
FAIL: AddressSanitizer-armhf-linux-dynamic::stack-use-after-return.cc
FAIL: AddressSanitizer-armhf-linux-dynamic::heavy_uar_test.cc
fail?

FOAD, once linaro-apm-05 is up after OS update, I'm going to connect it to silent master for 1-2 weeks to confirm stability. If everything is OK, I'll move it to main master.