[all-commits] [llvm/llvm-project] 2caf85: [ARM] implement LOAD_STACK_GUARD for remaining tar...

Ard Biesheuvel via All-commits all-commits at lists.llvm.org
Mon Nov 8 14:04:33 PST 2021


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 2caf85ad7ab83c441cb8e3550916d7028dfb8525
      https://github.com/llvm/llvm-project/commit/2caf85ad7ab83c441cb8e3550916d7028dfb8525
  Author: Ard Biesheuvel <ardb at google.com>
  Date:   2021-11-08 (Mon, 08 Nov 2021)

  Changed paths:
    M llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
    M llvm/lib/Target/ARM/ARMISelLowering.cpp
    M llvm/lib/Target/ARM/ARMInstrInfo.cpp
    M llvm/lib/Target/ARM/Thumb2InstrInfo.cpp
    M llvm/test/CodeGen/ARM/ssp-data-layout.ll
    M llvm/test/CodeGen/ARM/stack-guard-reassign.ll
    M llvm/test/CodeGen/ARM/struct_byval.ll
    M llvm/test/CodeGen/ARM/tail-call-scheduling.ll
    M llvm/test/CodeGen/ARM/win32-ssp.ll

  Log Message:
  -----------
  [ARM] implement LOAD_STACK_GUARD for remaining targets

Currently, LOAD_STACK_GUARD on ARM is only implemented for Mach-O targets, and
other targets rely on the generic support which may result in spilling of the
stack canary value or address, or may cause it to be kept in a callee save
register across function calls, which means they essentially get spilled as
well, only by the callee when it wants to free up this register.

So let's implement LOAD_STACK GUARD for other targets as well. This ensures
that the load of the stack canary is rematerialized fully in the epilogue.

This code was split off from

  D112768: [ARM] implement support for TLS register based stack protector

for which it is a prerequisite.

Reviewed By: nickdesaulniers

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




More information about the All-commits mailing list