[all-commits] [llvm/llvm-project] 94142d: [libclc] Support the generic address space (#137183)

[Fraser Cormack via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 94142d9bb08c523802cbfb3c316fc2ae9bb33b60
      https://github.com/llvm/llvm-project/commit/94142d9bb08c523802cbfb3c316fc2ae9bb33b60
  Author: Fraser Cormack <fraser at codeplay.com>
  Date:   2025-05-21 (Wed, 21 May 2025)

  Changed paths:
    M libclc/CMakeLists.txt
    M libclc/clc/include/clc/clcfunc.h
    M libclc/clc/include/clc/math/remquo_decl.inc
    M libclc/clc/include/clc/math/unary_decl_with_int_ptr.inc
    M libclc/clc/include/clc/math/unary_decl_with_ptr.inc
    M libclc/clc/include/clc/math/unary_def_with_int_ptr.inc
    M libclc/clc/include/clc/math/unary_def_with_ptr.inc
    M libclc/clc/lib/generic/math/clc_fract.inc
    M libclc/clc/lib/generic/math/clc_frexp.cl
    M libclc/clc/lib/generic/math/clc_modf.inc
    M libclc/clc/lib/generic/math/clc_remquo.cl
    M libclc/clc/lib/generic/math/clc_sincos.inc
    M libclc/opencl/include/clc/opencl/math/remquo.h
    M libclc/opencl/include/clc/opencl/shared/vload.h
    M libclc/opencl/include/clc/opencl/shared/vstore.h
    M libclc/opencl/lib/clspv/shared/vstore_half.inc
    M libclc/opencl/lib/generic/math/remquo.inc
    M libclc/opencl/lib/generic/shared/vload.cl
    M libclc/opencl/lib/generic/shared/vload_half.inc
    M libclc/opencl/lib/generic/shared/vstore.cl
    M libclc/opencl/lib/generic/shared/vstore_half.inc

  Log Message:
  -----------
  [libclc] Support the generic address space (#137183)

This commit provides definitions of builtins with the generic address
space.

One concept to consider is the difference between supporting the generic
address space from the user's perspective and the requirement for libclc
as a compiler implementation detail to define separate generic address
space builtins. In practice a target (like NVPTX) might notionally
support the generic address space, but it's mapped to the same LLVM
target address space as another address space (often the private one).

In such cases libclc must be careful not to define both private and
generic overloads of the same builtin. We track these two concepts
separately, and make the assumption that if the generic address space
does clash with another, it's with the private one. We track the
concepts separately because there are some builtins such as atomics that
are defined for the generic address space but not the private address
space.



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