[clang] [llvm] AMDGPU: Move enqueued block handling into clang (PR #128519)

2025-03-11 Thread Sameer Sahasrabuddhe via cfe-commits
https://github.com/ssahasra edited https://github.com/llvm/llvm-project/pull/128519 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] AMDGPU: Move enqueued block handling into clang (PR #128519)

2025-03-11 Thread Sameer Sahasrabuddhe via cfe-commits
@@ -1734,6 +1735,29 @@ define amdgpu_kernel void @unknown_addrspace_kernarg(ptr addrspace(12345) %ptr) ret void } +; Make sure the device_enqueue_symbol is not reported +; CHECK: - .args: [] +; CHECK-NEXT: .group_segment_fixed_size: 0 +; CHECK-NEXT: .kernarg_segme

[clang] [llvm] AMDGPU: Move enqueued block handling into clang (PR #128519)

2025-03-11 Thread Sameer Sahasrabuddhe via cfe-commits
@@ -0,0 +1,110 @@ +//===- AMDGPUExportKernelRuntimeHandles.cpp - Lower enqueued block ===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Ap

[clang] [llvm] AMDGPU: Move enqueued block handling into clang (PR #128519)

2025-03-11 Thread Sameer Sahasrabuddhe via cfe-commits
https://github.com/ssahasra commented: I don't have recent exposure to the OpenCL implementation, but generally eyeballed the code to make sure that the changes do what is described. Is there some confidence that the new scheme actually works? For example, maybe an existing CodeGen test where

[clang] [llvm] AMDGPU: Move enqueued block handling into clang (PR #128519)

2025-03-11 Thread Sameer Sahasrabuddhe via cfe-commits
@@ -1,23 +1,23 @@ -//===- AMDGPUOpenCLEnqueuedBlockLowering.h ---*- C++-*-===// +//===- AMDGPUExportKernelRuntimeHandles.h ---*- C++-*-===// ssahasra wrote: The requirement was dropped from the LLVM Coding Standards, and t

[clang] [clang] ``noconvergent`` does not affect calls to convergent functions (PR #132701)

2025-03-24 Thread Sameer Sahasrabuddhe via cfe-commits
https://github.com/ssahasra created https://github.com/llvm/llvm-project/pull/132701 When placed on a function, the ``clang::noconvergent`` attribute ensures that the function is not assumed to be convergent. But the same attribute has no effect on function calls. A call is convergent if the c

[clang] [clang] ``noconvergent`` does not affect calls to convergent functions (PR #132701)

2025-03-24 Thread Sameer Sahasrabuddhe via cfe-commits
https://github.com/ssahasra closed https://github.com/llvm/llvm-project/pull/132701 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [Driver][AMDGPU][HIP][SPIRV] Disable optimizations for AMDGCN SPIR-V (PR #154765)

2025-08-26 Thread Sameer Sahasrabuddhe via cfe-commits
ssahasra wrote: > SPIRV is a storage format and flavoring it as AMDGPU shouldn't introduce > unique optimization issues. If SPIRV is adding custom optimizations that is > harmful to the ultimate finalization, that's an issue to directly address in > the SPIRV optimizations. This seems to me a

[clang] [llvm] [Driver][AMDGPU][HIP][SPIRV] Disable optimizations for AMDGCN SPIR-V (PR #154765)

2025-08-28 Thread Sameer Sahasrabuddhe via cfe-commits
ssahasra wrote: For the record, I don't mean to hold up this patch with just my opinions, since clearly I am not the one spending time making SPIRV work for AMDGCN. Will defer to other people's review about the actual mechanics of the patch. https://github.com/llvm/llvm-project/pull/154765 ___

<    1   2