LGTM

There is also a test failure on the aarch64 2-stage bot (https://lab.llvm.org/buildbot/#/builders/7/builds/2720) which I've bisected to this change, so I'll revert it for now.

One of the tests was failing on the ARM/AArch64 bots because they don't build the X86 backend, I've moved that test to the X86-specific directory (rG6b3fb4714365).

I've reverted this (07e46367bae) because it was causing Bindings/Go/go.test to fail on the buoldbots. Example failure at http://lab.llvm.org:8011/#/builders/107/builds/6075.

Many of the tests added here are failing on the AArch64 buildbots (e.g. http://lab.llvm.org:8011/#/builders/7/builds/1974). Is this expected to work on AArch64, or should these tests be disabled for those bots?

This patch was causing failures on the AArch64 buildbots, because the compilers they use (clang 10.0 and gcc 9.3.0) don't accept these instructions when targeting armv8.0-a. I've committed https://reviews.llvm.org/rG0070c9ee2d2ce8 to use the hint mnemonic instead for these, which is supported by all aarch64 assemblers.

LGTM

• Rebase
• Also probe space allocated for outgoing call arguments when needed

While writing the comment in D98258, I noticed that we also move the stack pointer down for calls when a reserved call frame can't be used, which isn't probed by this patch.

• Rebase
• Check for unsupported stack probing methods

Ping

• Use TSFlags to check for thumb instructions, and walk operands to find the immediate, to avoid needing to keep the switch statement up to date
• Don't include instruction encodings in test

• Test with both ARM and Thumb triples
• Fix failing lld test, where this bug was causing the wrong symbols to be displayed

Ping

Ping.

I think it would be better to disable (or change the CFLAGS for, is possible) the one test (is this the same one discussed in D96490?), than to change the config of the whole test suite.

LGTM

There are lists of tests to skip for each architecture in SingleSource/Regression/C/gcc-c-torture/execute/CMakeLists.txt, that looks like the right place to do this. I'm not sure if it's possible to know if global-isel is enabled in that file, but since it's just one test I think disabling it for all Arm and AArch64 bots is ok.

The test-suite is the only thing this bot does to test global-isel, so I don't think there's any point in running the bot with this change. I think our options here are:

• Disable just the tests which are failing (looks like it's just test-suite::GCC-C-execute-eeprof-1.test?)
• Convert this to a 2-stage bot with the second stage built using global-isel, so that we are still doing some useful testing
• Disable this bot completely until https://bugs.llvm.org/show_bug.cgi?id=49143 is fixed.

LGTM

Ping.

Could this also affect regular users of the sanitizers, or is it specific to the way we are running the tests? If it could affect users, then could we fix this in the clang driver, so that unwind tables are turned on by default whenever the sanitizers need them?

• Assert if types aren't what we expect, instead of emitting an un-probed SP move.
• Share code with LegalizerHelper
• Add MIR tests for the legalizer

LGTM

Committed as rG3676ef1053.

Ping.

This is causing compiler crashes during the second stage of the 2-stage buildbots (e.g. http://lab.llvm.org:8011/#/builders/7/builds/1140), so I've reverted it in rG76f6b125cef1.

This is causing a build failure on the 32-bit ARM bots:

Committed as 224328460d75e1fa16a23901b3aa494b89e0a842.

Ok, LGTM

LGTM

LGTM

LGTM

LGTM

LGTM

LGTM

LGTM

LGTM

LGTM

Why is this restricted to v7-A or later? The DSB and ISB instructions have existed since v6T2 and v6M.

LGTM

The code changes look good, but this is missing tests for the new TLBI operands..

LGTM

LGTM with one minor comment.

LGTM

The pre-commit test failures look relevant, so should be investigated.

LGTM

LGTM

LGTM

Also, __fp16 is a storage format and promoted to 'float' for argument passing

LGTM

They are enabled iff the compiler supports _Float16.

LGTM

LGTM

I'm not aware of any official policy about this, but I don't think it's worth going through a multi-release deprecation process for something which is called out in the architecture manual as not valid.