[all-commits] [llvm/llvm-project] 994d2b: AMDGPU: Stop emitting an error on illegal addrspac...

[Matt Arsenault via All-commits]

  Branch: refs/heads/users/arsenm/amdgpu/no-error-on-invalid-addrspacecast
  Home:   https://github.com/llvm/llvm-project
  Commit: 994d2be37eace0550189da94c6f1f9b9a937cd2c
      https://github.com/llvm/llvm-project/commit/994d2be37eace0550189da94c6f1f9b9a937cd2c
  Author: Matt Arsenault <Matthew.Arsenault at amd.com>
  Date:   2025-02-17 (Mon, 17 Feb 2025)

  Changed paths:
    M llvm/lib/Target/AMDGPU/AMDGPULegalizerInfo.cpp
    M llvm/lib/Target/AMDGPU/SIISelLowering.cpp
    M llvm/test/CodeGen/AMDGPU/atomicrmw-expand.ll
    M llvm/test/CodeGen/AMDGPU/invalid-addrspacecast.ll

  Log Message:
  -----------
  AMDGPU: Stop emitting an error on illegal addrspacecasts

These cannot be static compile errors, and should be treated as
poison. Invalid casts may be introduced which are dynamically dead.

For example:

  void foo(volatile generic int* x) {
    __builtin_assume(is_shared(x));
   *x = 4;
  }

  void bar() {
    private int y;
    foo(&y); // violation, wrong address space
  }

This could produce a compile time backend error or not depending on
the optimization level. Similarly, the new test demonstrates a failure
on a lowered atomicrmw which required inserting runtime address
space checks. The invalid cases are dynamically dead, we should not
error, and the AtomicExpand pass shouldn't have to consider the details
of the incoming pointer to produce valid IR.

This should go to the release branch. This fixes broken -O0 compiles
with 64-bit atomics which would have started failing in
1d0370872f28ec9965448f33db1b105addaf64ae.



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