- User Since
- Apr 11 2019, 6:15 AM (114 w, 9 h)
May 13 2021
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.
Mar 30 2021
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).
Mar 29 2021
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.
Mar 11 2021
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.
Mar 10 2021
Mar 9 2021
- 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.
- Check for unsupported stack probing methods
Mar 8 2021
Mar 4 2021
- 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
Mar 2 2021
- Test with both ARM and Thumb triples
- Fix failing lld test, where this bug was causing the wrong symbols to be displayed
Feb 18 2021
Feb 11 2021
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.
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.
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?
Feb 8 2021
- 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
Feb 5 2021
Feb 4 2021
Jan 29 2021
Jan 28 2021
Jan 15 2021
Committed as rG3676ef1053.
Jan 14 2021
Jan 7 2021
Jan 6 2021
This is causing a build failure on the 32-bit ARM bots:
Committed as 224328460d75e1fa16a23901b3aa494b89e0a842.
Jan 5 2021
Dec 18 2020
Dec 17 2020
Why is this restricted to v7-A or later? The DSB and ISB instructions have existed since v6T2 and v6M.
Dec 8 2020
The code changes look good, but this is missing tests for the new TLBI operands..
Dec 7 2020
Dec 3 2020
Nov 19 2020
LGTM with one minor comment.
The pre-commit test failures look relevant, so should be investigated.
Also, __fp16 is a storage format and promoted to 'float' for argument passing
Nov 18 2020
They are enabled iff the compiler supports _Float16.
Nov 6 2020
Oct 27 2020
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.