[all-commits] [llvm/llvm-project] 9392b4: AMDGPU/GlobalISel: Fix selection of constant 32-bi...

[Matt Arsenault via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 9392b40d4b1999c9b33490829552d928a2fa9bab
      https://github.com/llvm/llvm-project/commit/9392b40d4b1999c9b33490829552d928a2fa9bab
  Author: Matt Arsenault <Matthew.Arsenault at amd.com>
  Date:   2022-01-17 (Mon, 17 Jan 2022)

  Changed paths:
    M llvm/lib/Target/AMDGPU/AMDGPUInstructions.td
    A llvm/test/CodeGen/AMDGPU/GlobalISel/load-constant32bit.ll

  Log Message:
  -----------
  AMDGPU/GlobalISel: Fix selection of constant 32-bit addrspace loads

Unfortunately the selection patterns still rely on the address space
from the memory operand instead of using the pointer type. Add this
address space to the list of cases supported by global-like loads.

Alternatively we would have to adjust the address space of the memory
operand to deviate from the underlying IR value, which looks ugly and
is more work in the legalizer.

This doesn't come up in the DAG path because it uses a different
selection strategy where the cast is inserted during the addressing
mode matching.


  Commit: dc2457c8cf096b35e3addb7fceb252d90803430f
      https://github.com/llvm/llvm-project/commit/dc2457c8cf096b35e3addb7fceb252d90803430f
  Author: Matt Arsenault <Matthew.Arsenault at amd.com>
  Date:   2022-01-17 (Mon, 17 Jan 2022)

  Changed paths:
    M llvm/lib/Target/AMDGPU/AMDGPUCallLowering.cpp
    M llvm/lib/Target/AMDGPU/SIISelLowering.cpp
    M llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call.ll
    M llvm/test/CodeGen/AMDGPU/amdpal-callable.ll
    A llvm/test/CodeGen/AMDGPU/gfx-call-non-gfx-func.ll

  Log Message:
  -----------
  AMDGPU: Fix crashing on calls to C functions from graphics contexts

If we had one of the shader calling conventions calling a default
calling convention callee, this would crash when the caller did not
have anything to pass to the workitem ID.

This is illegal, but we still need to produce something
sensible. llvm-reduce likes to replace calls to intrinsics with calls
to null or undef, so this does appear and is helpful to avoid hard
erroring.

Pass undef in this case, as already happened for the other implicit
arguments. It might make sense to define the behavior here and pass
null for the pointers, and -1 for the workitem ID. We do have extra
bits in the workitem ID, so this wouldn't conflict with a valid value.


Compare: https://github.com/llvm/llvm-project/compare/0b1140e88352...dc2457c8cf09