[all-commits] [llvm/llvm-project] 3859fc: AArch64: Switch to x20 as the shadow base register...

[pcc via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 3859fc653fb49f4acfb61b6f2c38736ec9bfae06
      https://github.com/llvm/llvm-project/commit/3859fc653fb49f4acfb61b6f2c38736ec9bfae06
  Author: Peter Collingbourne <peter at pcc.me.uk>
  Date:   2020-10-30 (Fri, 30 Oct 2020)

  Changed paths:
    M clang/docs/HardwareAssistedAddressSanitizerDesign.rst
    M compiler-rt/test/hwasan/TestCases/register-dump-read.c
    M llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
    M llvm/lib/Target/AArch64/AArch64InstrInfo.td
    M llvm/test/CodeGen/AArch64/hwasan-check-memaccess.ll

  Log Message:
  -----------
  AArch64: Switch to x20 as the shadow base register for outlined HWASan checks.

>From a code size perspective it turns out to be better to use a
callee-saved register to pass the shadow base. For non-leaf functions
it avoids the need to reload the shadow base into x9 after each
function call, at the cost of an additional stack slot to save the
caller's x20. But with x9 there is also a stack size cost, either
as a result of copying x9 to a callee-saved register across calls or
by spilling it to stack, so for the non-leaf functions the change to
stack usage is largely neutral.

It is also code size (and stack size) neutral for many leaf functions.
Although they now need to save/restore x20 this can typically be
combined via LDP/STP into the x30 save/restore. In the case where
the function needs callee-saved registers or stack spills we end up
needing, on average, 8 more bytes of stack and 1 more instruction
but given the improvements to other functions this seems like the
right tradeoff.

Unfortunately we cannot change the register for the v1 (non short
granules) check because the runtime assumes that the shadow base
register is stored in x9, so the v1 check still uses x9.

Aside from that there is no change to the ABI because the choice
of shadow base register is a contract between the caller and the
outlined check function, both of which are compiler generated. We do
need to rename the v2 check functions though because the functions
are deduplicated based on their names, not on their contents, and we
need to make sure that when object files from old and new compilers
are linked together we don't end up with a function that uses x9
calling an outlined check that uses x20 or vice versa.

With this change code size of /system/lib64/*.so in an Android build
with HWASan goes from 200066976 bytes to 194085912 bytes, or a 3%
decrease.

Differential Revision: https://reviews.llvm.org/D90422