FailedChanges

Summary

  1. [test] Fix FullUnroll.ll (details)
  2. [AArch64] Enable implicit null check transformation (details)
  3. [RISCV] Support Shadow Call Stack (details)
  4. [MLIR][TableGen] Automatic detection and elimination of redundant methods (details)
Commit f2f0474c93ee67421fae007528ae4be20ae384f8 by aeubanks
[test] Fix FullUnroll.ll

I believe the intention of this test added in
https://reviews.llvm.org/D71687 was to test LoopFullUnrollPass with
clang's -fno-unroll-loops, not its interaction with optnone. Loop
unrolling passes don't run under optnone/-O0.

Also added back unintentionally removed -disable-loop-unrolling from
https://reviews.llvm.org/D85578.

Reviewed By: echristo

Differential Revision: https://reviews.llvm.org/D86485
The file was modifiedllvm/test/Transforms/LoopUnroll/FullUnroll.ll (diff)
Commit b04c181ed776c344e6f5e2653a22bc6e5746834a by listmail
[AArch64] Enable implicit null check transformation

This change enables the generic implicit null transformation for the AArch64 target. As background for those unfamiliar with our implicit null check support:

    An implicit null check is the use of a signal handler to catch and redirect to a handler a null pointer. Specifically, it's replacing an explicit conditional branch with such a redirect. This is only done for very cold branches under frontend control w/appropriate metadata.
    FAULTING_OP is used to wrap the faulting instruction. It is modelled as being a conditional branch to reflect the fact it can transfer control in the CFG.
    FAULTING_OP does not need to be an analyzable branch to achieve it's purpose. (Or at least, that's the x86 model. I find this slightly questionable.)
    When lowering to MC, we convert the FAULTING_OP back into the actual instruction, record the labels, and lower the original instruction.

As can be seen in the test changes, currently the AArch64 backend does not eliminate the unconditional branch to the fallthrough block. I've tried two approaches, neither of which worked. I plan to return to this in a separate change set once I've wrapped my head around the interactions a bit better. (X86 handles this via AllowModify on analyzeBranch, but adding the obvious code causing BranchFolding to crash. I haven't yet figured out if it's a latent bug in BranchFolding, or something I'm doing wrong.)

Differential Revision: https://reviews.llvm.org/D87851
The file was modifiedllvm/lib/CodeGen/BranchRelaxation.cpp (diff)
The file was modifiedllvm/lib/Target/AArch64/AArch64AsmPrinter.cpp (diff)
The file was modifiedllvm/lib/Target/AArch64/AArch64InstrInfo.h (diff)
The file was modifiedllvm/test/CodeGen/AArch64/implicit-null-check.ll (diff)
The file was modifiedllvm/lib/CodeGen/ImplicitNullChecks.cpp (diff)
The file was modifiedllvm/lib/Target/AArch64/AArch64InstrInfo.cpp (diff)
Commit 1c466477ad468d8a18c43b738df7b7fc6213e9a8 by zhaoshiz
[RISCV] Support Shadow Call Stack

Currenlty assume x18 is used as pointer to shadow call stack. User shall pass
flags:

"-fsanitize=shadow-call-stack -ffixed-x18"

Runtime supported is needed to setup x18.

If SCS is desired, all parts of the program should be built with -ffixed-x18 to
maintain inter-operatability.

There's no particuluar reason that we must use x18 as SCS pointer. Any register
may be used, as long as it does not have designated purpose already, like RA or
passing call arguments.

Differential Revision: https://reviews.llvm.org/D84414
The file was modifiedclang/lib/Driver/ToolChain.cpp (diff)
The file was modifiedclang/test/Driver/sanitizer-ld.c (diff)
The file was modifiedllvm/lib/Target/RISCV/Utils/RISCVBaseInfo.h (diff)
The file was addedllvm/test/CodeGen/RISCV/shadowcallstack.ll
The file was modifiedllvm/lib/Target/RISCV/RISCVFrameLowering.cpp (diff)
The file was modifiedclang/lib/Driver/SanitizerArgs.cpp (diff)
The file was modifiedllvm/lib/Target/RISCV/Utils/RISCVBaseInfo.cpp (diff)
The file was modifiedclang/test/CodeGen/shadowcallstack-attr.c (diff)
Commit 8069844577d47f503cb71644f2e58e0237d5b539 by jurahul
[MLIR][TableGen] Automatic detection and elimination of redundant methods

- Change OpClass new method addition to find and eliminate any existing methods that
  are made redundant by the newly added method, as well as detect if the newly added
  method will be redundant and return nullptr in that case.
- To facilitate that, add the notion of resolved and unresolved parameters, where resolved
  parameters have each parameter type known, so that redundancy checks on methods
  with same name but different parameter types can be done.
- Eliminate existing code to avoid adding conflicting/redundant build methods and rely
  on this new mechanism to eliminate conflicting build methods.

Fixes https://bugs.llvm.org/show_bug.cgi?id=47095

Differential Revision: https://reviews.llvm.org/D87059
The file was modifiedmlir/test/mlir-tblgen/op-attribute.td (diff)
The file was modifiedmlir/test/mlir-tblgen/op-result.td (diff)
The file was modifiedmlir/tools/mlir-tblgen/OpDefinitionsGen.cpp (diff)
The file was modifiedmlir/lib/TableGen/OpClass.cpp (diff)
The file was modifiedmlir/tools/mlir-tblgen/OpFormatGen.cpp (diff)
The file was modifiedmlir/include/mlir/TableGen/OpClass.h (diff)