[all-commits] [llvm/llvm-project] 7defbf: [StackProtector] Add test for atomicrmw xchg (NFC)

[Nikita Popov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 7defbf987a551771c275129c70fe4e59dc5125cc
      https://github.com/llvm/llvm-project/commit/7defbf987a551771c275129c70fe4e59dc5125cc
  Author: Nikita Popov <npopov at redhat.com>
  Date:   2025-02-27 (Thu, 27 Feb 2025)

  Changed paths:
    A llvm/test/CodeGen/X86/stack-protector-atomicrmw-xchg.ll

  Log Message:
  -----------
  [StackProtector] Add test for atomicrmw xchg (NFC)

This is an opt based test because usually AtomicExpand will
convert it to an integer atomicrmw first.


  Commit: b2aba39001f6909965c4a9af47969e83717601c0
      https://github.com/llvm/llvm-project/commit/b2aba39001f6909965c4a9af47969e83717601c0
  Author: Nikita Popov <npopov at redhat.com>
  Date:   2025-02-27 (Thu, 27 Feb 2025)

  Changed paths:
    M llvm/lib/CodeGen/StackProtector.cpp
    M llvm/test/CodeGen/X86/stack-protector-atomicrmw-xchg.ll

  Log Message:
  -----------
  [StackProtector] Handle atomicrmw xchg in HasAddressTaken heuristic

Atomicrmw xchg can directly take a pointer operand, so we should
treat it similarly to store or cmpxchg.

In practice, I believe that all targets that support stack protectors
will convert this to an integer atomicrmw xchg in AtomicExpand, so
there is no issue in practice. We still should handle it correctly
if that doesn't happen.


Compare: https://github.com/llvm/llvm-project/compare/8635b8eb5178...b2aba39001f6

To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications