[clang] [clang][OpenCL][CodeGen][AMDGPU] Do not use `private` as the default AS for when `generic` is available (PR #112442)

@@ -1,67 +1,111 @@ -// RUN: %clang_cc1 -O0 -cl-std=CL1.2 -triple amdgcn---amdgizcl -emit-llvm %s -o - | FileCheck -check-prefixes=CHECK,CL12 %s -// RUN: %clang_cc1 -O0 -cl-std=CL2.0 -triple amdgcn---amdgizcl -emit-llvm %s -o - | FileCheck -check-prefixes=CHECK,CL20 %s +// NOTE:

[clang] [llvm] [clang][llvm][SPIR-V] Explicitly encode native integer widths for SPIR-V (PR #110695)

@@ -1,12 +1,14 @@ ; This test aims to check ability to support "Arithmetic with Overflow" intrinsics ; in the special case when those intrinsics are being generated by the CodeGenPrepare; -; pass during translations with optimization (note -O3 in llc arguments). +; pass during

[clang] [llvm] [llvm][opt][Transforms][SPIR-V] Enable `InferAddressSpaces` for SPIR-V (PR #110897)

https://github.com/AlexVlx created https://github.com/llvm/llvm-project/pull/110897 Albeit not currently enabled, the InferAddressSpaces pass is desirable / profitable for SPIR-V, as it can leverage info that might subsequently be lost as transforms are applied to the IR/resulting SPIR-V. This

[clang] [llvm] [llvm][opt][Transforms][SPIR-V] Enable `InferAddressSpaces` for SPIR-V (PR #110897)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/110897 >From 9f3cac44dde7d0adcf6cd090c0b91f57cb1c4dca Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Wed, 2 Oct 2024 11:18:36 +0100 Subject: [PATCH 1/2] Enable `InferAddressSpaces` for SPIR-V. --- .../amdgpu-kernel-

[clang] [Clang][HIP] Warn when __AMDGCN_WAVEFRONT_SIZE is used in host code without relying on target-dependent overload resolution (PR #109663)

AlexVlx wrote: > > I don't think we should rely on these on the host at all, the addition was > > a design mistake initially, we probably should not double down on it. > > I agree with it in principle. However, removing things that already exist > should be done with consideration for the exis

[clang] [Clang][HIP] Warn when __AMDGCN_WAVEFRONT_SIZE is used in host code without relying on target-dependent overload resolution (PR #109663)

AlexVlx wrote: Just because somebody wrote something we should not assume it is necessarily sound or valid. Is there some illustration of said valid uses / have the users made an argument around why they absolutely must have the macro? CUDA doesn't have a macro like this at all AFAIK, and ever

[clang] [clang][HIP] Don't use the OpenCLKernel CC when targeting AMDGCNSPIRV (PR #110447)

https://github.com/AlexVlx closed https://github.com/llvm/llvm-project/pull/110447 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][OpenCL][CodeGen][AMDGPU] Do not use `private` as the default AS for when `generic` is available (PR #112442)

https://github.com/AlexVlx closed https://github.com/llvm/llvm-project/pull/112442 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [clang][llvm][SPIR-V] Explicitly encode native integer widths for SPIR-V (PR #110695)

@@ -1,12 +1,14 @@ ; This test aims to check ability to support "Arithmetic with Overflow" intrinsics ; in the special case when those intrinsics are being generated by the CodeGenPrepare; -; pass during translations with optimization (note -O3 in llc arguments). +; pass during

[clang] [clang][OpenCL][CodeGen][AMDGPU] Do not use `private` as the default AS for when `generic` is available (PR #112442)

AlexVlx wrote: > LLVM Buildbot has detected a new failure on builder > `openmp-offload-amdgpu-runtime` running on `omp-vega20-0` while building > `clang` at step 7 "Add check check-offload". > > Full details are available at: > https://lab.llvm.org/buildbot/#/builders/30/builds/8694 > > Here

[clang] [clang][HIP] Don't use the OpenCLKernel CC when targeting AMDGCNSPIRV (PR #110447)

https://github.com/AlexVlx commented: Gentle ping. https://github.com/llvm/llvm-project/pull/110447 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][HIP] Don't use the OpenCLKernel CC when targeting AMDGCNSPIRV (PR #110447)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/110447 >From f65d933740225122d832a340b89fe4da0d80a204 Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Mon, 30 Sep 2024 03:09:58 +0100 Subject: [PATCH] Don't use the OpenCLKernel CC when targeting AMDGCNSPIRV. --- cla

[clang] [clang][HIP] Don't use the OpenCLKernel CC when targeting AMDGCNSPIRV (PR #110447)

https://github.com/AlexVlx edited https://github.com/llvm/llvm-project/pull/110447 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][HIP] Don't use the OpenCLKernel CC when targeting AMDGCNSPIRV (PR #110447)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/110447 >From f65d933740225122d832a340b89fe4da0d80a204 Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Mon, 30 Sep 2024 03:09:58 +0100 Subject: [PATCH] Don't use the OpenCLKernel CC when targeting AMDGCNSPIRV. --- cla

[clang] [llvm] [llvm][opt][Transforms][SPIR-V] Enable `InferAddressSpaces` for SPIR-V (PR #110897)

@@ -91,6 +97,100 @@ SPIRVTargetMachine::SPIRVTargetMachine(const Target &T, const Triple &TT, setRequiresStructuredCFG(false); } +enum AddressSpace { + Function = storageClassToAddressSpace(SPIRV::StorageClass::Function), + CrossWorkgroup = + storageClassToAddressSpa

[clang] [clang][HIP] Don't use the OpenCLKernel CC when targeting AMDGCNSPIRV (PR #110447)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/110447 >From f65d933740225122d832a340b89fe4da0d80a204 Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Mon, 30 Sep 2024 03:09:58 +0100 Subject: [PATCH] Don't use the OpenCLKernel CC when targeting AMDGCNSPIRV. --- cla

[clang] [llvm] [llvm][opt][Transforms][SPIR-V] Enable `InferAddressSpaces` for SPIR-V (PR #110897)

@@ -91,6 +97,88 @@ SPIRVTargetMachine::SPIRVTargetMachine(const Target &T, const Triple &TT, setRequiresStructuredCFG(false); } +enum AddressSpace { + Function = storageClassToAddressSpace(SPIRV::StorageClass::Function), + CrossWorkgroup = + storageClassToAddressSpac

[clang] [clang][CodeGen][OpenCL] Fix `alloca` handling & `sret`when compiling for (PR #113930)

@@ -108,11 +108,15 @@ RawAddress CodeGenFunction::CreateTempAlloca(llvm::Type *Ty, CharUnits Align, if (AllocaAddr) *AllocaAddr = Alloca; llvm::Value *V = Alloca.getPointer(); + assert((!getLangOpts().OpenCL || + CGM.getTarget().getTargetAddressSpace(getASTAl

[clang] [clang][CodeGen] `sret` args should always point to the `alloca` AS, so use that (PR #114062)

@@ -5390,11 +5391,19 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo &CallInfo, V->getType()->isIntegerTy()) V = Builder.CreateZExt(V, ArgInfo.getCoerceToType()); -// If the argument doesn't match, perform a bitcast to coerce it. This -

[clang] [clang][CodeGen] `sret` args should always point to the `alloca` AS, so use that (PR #114062)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/114062 >From d2d2d3d5db3f639aab178f9ca9a20db2842d2b65 Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Tue, 29 Oct 2024 14:20:44 + Subject: [PATCH 1/2] `sret` args should always point to the `alloca` AS, so we can

[clang] [clang][CodeGen] `sret` args should always point to the `alloca` AS, so use that (PR #114062)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/114062 >From d2d2d3d5db3f639aab178f9ca9a20db2842d2b65 Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Tue, 29 Oct 2024 14:20:44 + Subject: [PATCH 1/3] `sret` args should always point to the `alloca` AS, so we can

[clang] [clang][CodeGen] `sret` args should always point to the `alloca` AS, so use that (PR #114062)

https://github.com/AlexVlx edited https://github.com/llvm/llvm-project/pull/114062 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][CodeGen] `sret` args should always point to the `alloca` AS, so use that (PR #114062)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/114062 >From d2d2d3d5db3f639aab178f9ca9a20db2842d2b65 Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Tue, 29 Oct 2024 14:20:44 + Subject: [PATCH 1/2] `sret` args should always point to the `alloca` AS, so we can

[clang] [clang][CodeGen] `sret` args should always point to the `alloca` AS, so use that (PR #114062)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/114062 >From d2d2d3d5db3f639aab178f9ca9a20db2842d2b65 Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Tue, 29 Oct 2024 14:20:44 + Subject: [PATCH] `sret` args should always point to the `alloca` AS, so we can use

[clang] [clang][CodeGen] `sret` args should always point to the `alloca` AS, so use that (PR #114062)

https://github.com/AlexVlx created https://github.com/llvm/llvm-project/pull/114062 `sret` arguments are always going to reside in the stack/`alloca` address space, which makes the current formulation where their AS is derived from the pointee somewhat quaint. This patch ensures that `sret` en

[clang] [clang][CodeGen][OpenCL] Fix `alloca` handling & `sret`when compiling for (PR #113930)

@@ -108,11 +108,15 @@ RawAddress CodeGenFunction::CreateTempAlloca(llvm::Type *Ty, CharUnits Align, if (AllocaAddr) *AllocaAddr = Alloca; llvm::Value *V = Alloca.getPointer(); + assert((!getLangOpts().OpenCL || + CGM.getTarget().getTargetAddressSpace(getASTAl

[clang] [clang][CodeGen] `sret` args should always point to the `alloca` AS, so use that (PR #114062)

https://github.com/AlexVlx commented: > Is this a target-independent decision? I could certainly imagine a target > with a generic AS wanting to specify that indirect return addresses (and > maybe even parameters?) should be in that rather than the alloca AS; among > other things, it would al

[clang] [clang][CodeGen] `sret` args should always point to the `alloca` AS, so use that (PR #114062)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/114062 >From d2d2d3d5db3f639aab178f9ca9a20db2842d2b65 Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Tue, 29 Oct 2024 14:20:44 + Subject: [PATCH 1/4] `sret` args should always point to the `alloca` AS, so we can

[clang] [llvm] [opt][AMDGPU] Add pass to handle AMDGCN pseudo-intrinsics, start with `llvm.amdgcn.wavefrontsize` (PR #114481)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/114481 >From 3ba88ce598aaab269169f0a5db5981c9a9ac8603 Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Thu, 31 Oct 2024 22:38:36 + Subject: [PATCH 1/4] Add pass to handle AMDGCN pseudo-intrinsics (abstract placehol

[clang] [llvm] [llvm][AMDGPU] Fold `llvm.amdgcn.wavefrontsize` early (PR #114481)

@@ -744,7 +744,10 @@ void AMDGPUTargetMachine::registerPassBuilderCallbacks(PassBuilder &PB) { #include "llvm/Passes/TargetPassRegistry.inc" PB.registerPipelineStartEPCallback( - [](ModulePassManager &PM, OptimizationLevel Level) { + [this](ModulePassManager &PM,

[clang] [llvm] [llvm][AMDGPU] Fold `llvm.amdgcn.wavefrontsize` early (PR #114481)

AlexVlx wrote: > This is really just a constant folding rather than a new pass. If the concern > is that InstCombine works too late that is possible to add an earlier > invocation. Done. https://github.com/llvm/llvm-project/pull/114481 ___ cfe-commi

[clang] [llvm] [llvm][AMDGPU] Fold `llvm.amdgcn.wavefrontsize` early (PR #114481)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/114481 >From 3ba88ce598aaab269169f0a5db5981c9a9ac8603 Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Thu, 31 Oct 2024 22:38:36 + Subject: [PATCH 1/7] Add pass to handle AMDGCN pseudo-intrinsics (abstract placehol

[clang] [llvm] [llvm][AMDGPU] Fold `llvm.amdgcn.wavefrontsize` early (PR #114481)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/114481 >From 3ba88ce598aaab269169f0a5db5981c9a9ac8603 Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Thu, 31 Oct 2024 22:38:36 + Subject: [PATCH 1/6] Add pass to handle AMDGCN pseudo-intrinsics (abstract placehol

[clang] [llvm] [llvm][AMDGPU] Fold `llvm.amdgcn.wavefrontsize` early (PR #114481)

@@ -1024,6 +1024,15 @@ GCNTTIImpl::instCombineIntrinsic(InstCombiner &IC, IntrinsicInst &II) const { } break; } + case Intrinsic::amdgcn_wavefrontsize: { +// TODO: this is a workaround for the pseudo-generic target one gets with no +// specified mcpu, which

[clang] [llvm] [llvm][AMDGPU] Fold `llvm.amdgcn.wavefrontsize` early (PR #114481)

@@ -1024,6 +1024,15 @@ GCNTTIImpl::instCombineIntrinsic(InstCombiner &IC, IntrinsicInst &II) const { } break; } + case Intrinsic::amdgcn_wavefrontsize: { +// TODO: this is a workaround for the pseudo-generic target one gets with no +// specified mcpu, which

[clang] [llvm] [llvm][AMDGPU] Fold `llvm.amdgcn.wavefrontsize` early (PR #114481)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/114481 >From 3ba88ce598aaab269169f0a5db5981c9a9ac8603 Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Thu, 31 Oct 2024 22:38:36 + Subject: [PATCH 1/8] Add pass to handle AMDGCN pseudo-intrinsics (abstract placehol

[clang] [llvm] [opt][AMDGPU] Add pass to handle AMDGCN pseudo-intrinsics, start with `llvm.amdgcn.wavefrontsize` (PR #114481)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/114481 >From 3ba88ce598aaab269169f0a5db5981c9a9ac8603 Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Thu, 31 Oct 2024 22:38:36 + Subject: [PATCH 1/5] Add pass to handle AMDGCN pseudo-intrinsics (abstract placehol

[clang] [llvm] [llvm][AMDGPU] Fold `llvm.amdgcn.wavefrontsize` early (PR #114481)

https://github.com/AlexVlx edited https://github.com/llvm/llvm-project/pull/114481 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][Driver][HIP] Add support for mixing AMDGCNSPIRV & concrete `offload-arch`s. (PR #113509)

https://github.com/AlexVlx closed https://github.com/llvm/llvm-project/pull/113509 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [clang][llvm][SPIR-V] Explicitly encode native integer widths for SPIR-V (PR #110695)

https://github.com/AlexVlx closed https://github.com/llvm/llvm-project/pull/110695 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][CodeGen] `sret` args should always point to the `alloca` AS, so use that (PR #114062)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/114062 >From d2d2d3d5db3f639aab178f9ca9a20db2842d2b65 Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Tue, 29 Oct 2024 14:20:44 + Subject: [PATCH 1/5] `sret` args should always point to the `alloca` AS, so we can

[clang] [llvm] [llvm][AMDGPU] Fold `llvm.amdgcn.wavefrontsize` early (PR #114481)

@@ -1024,6 +1024,16 @@ GCNTTIImpl::instCombineIntrinsic(InstCombiner &IC, IntrinsicInst &II) const { } break; } + case Intrinsic::amdgcn_wavefrontsize: { +// TODO: this is a workaround for the pseudo-generic target one gets with no +// specified mcpu, which

[clang] [llvm] [llvm][AMDGPU] Fold `llvm.amdgcn.wavefrontsize` early (PR #114481)

https://github.com/AlexVlx edited https://github.com/llvm/llvm-project/pull/114481 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [llvm][AMDGPU] Fold `llvm.amdgcn.wavefrontsize` early (PR #114481)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/114481 >From 3ba88ce598aaab269169f0a5db5981c9a9ac8603 Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Thu, 31 Oct 2024 22:38:36 + Subject: [PATCH 1/9] Add pass to handle AMDGCN pseudo-intrinsics (abstract placehol

[clang] [llvm] [llvm][AMDGPU] Fold `llvm.amdgcn.wavefrontsize` early (PR #114481)

@@ -1024,6 +1024,15 @@ GCNTTIImpl::instCombineIntrinsic(InstCombiner &IC, IntrinsicInst &II) const { } break; } + case Intrinsic::amdgcn_wavefrontsize: { +// TODO: this is a workaround for the pseudo-generic target one gets with no +// specified mcpu, which

[clang] [llvm] [llvm][AMDGPU] Fold `llvm.amdgcn.wavefrontsize` early (PR #114481)

@@ -1024,6 +1024,15 @@ GCNTTIImpl::instCombineIntrinsic(InstCombiner &IC, IntrinsicInst &II) const { } break; } + case Intrinsic::amdgcn_wavefrontsize: { +// TODO: this is a workaround for the pseudo-generic target one gets with no +// specified mcpu, which

[clang] [llvm] [llvm][AMDGPU] Fold `llvm.amdgcn.wavefrontsize` early (PR #114481)

@@ -6,48 +7,78 @@ ; RUN: opt -O3 -S < %s | FileCheck -check-prefix=OPT %s ; RUN: opt -mtriple=amdgcn-- -O3 -S < %s | FileCheck -check-prefix=OPT %s -; RUN: opt -mtriple=amdgcn-- -O3 -mattr=+wavefrontsize32 -S < %s | FileCheck -check-prefix=OPT %s -; RUN: opt -mtriple=amdgcn--

[clang] [clang][CodeGen] `sret` args should always point to the `alloca` AS, so use that (PR #114062)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/114062 >From d2d2d3d5db3f639aab178f9ca9a20db2842d2b65 Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Tue, 29 Oct 2024 14:20:44 + Subject: [PATCH 1/5] `sret` args should always point to the `alloca` AS, so we can

[clang] [llvm] [opt][AMDGPU] Add pass to handle AMDGCN pseudo-intrinsics, start with `llvm.amdgcn.wavefrontsize` (PR #114481)

https://github.com/AlexVlx edited https://github.com/llvm/llvm-project/pull/114481 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [opt][AMDGPU] Add pass to handle AMDGCN pseudo-intrinsics, start with `llvm.amdgcn.wavefrontsize` (PR #114481)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/114481 >From 3ba88ce598aaab269169f0a5db5981c9a9ac8603 Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Thu, 31 Oct 2024 22:38:36 + Subject: [PATCH 1/4] Add pass to handle AMDGCN pseudo-intrinsics (abstract placehol

[clang] [clang][CodeGen] `sret` args should always point to the `alloca` AS, so use that (PR #114062)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/114062 >From d2d2d3d5db3f639aab178f9ca9a20db2842d2b65 Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Tue, 29 Oct 2024 14:20:44 + Subject: [PATCH 1/3] `sret` args should always point to the `alloca` AS, so we can

[clang] [clang][Driver][HIP] Add support for mixing AMDGCNSPIRV & concrete `offload-arch`s. (PR #113509)

AlexVlx wrote: Gentle ping. https://github.com/llvm/llvm-project/pull/113509 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][CodeGen] `sret` args should always point to the `alloca` AS, so use that (PR #114062)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/114062 >From d2d2d3d5db3f639aab178f9ca9a20db2842d2b65 Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Tue, 29 Oct 2024 14:20:44 + Subject: [PATCH 1/5] `sret` args should always point to the `alloca` AS, so we can

[clang] [clang][CodeGen] `sret` args should always point to the `alloca` AS, so use that (PR #114062)

@@ -23,8 +25,10 @@ X Test() // sret argument. // CHECK-CXX98: call void @_ZN1XC1ERKS_( // CHECK-CXX11: call void @_ZN1XC1EOS_( + // CHECK-CXX11-NONZEROALLOCAAS: call void @_ZN1XC1EOS_( AlexVlx wrote: Made an attempt to. https://github.com/llvm/llvm-pro

[clang] [clang][CodeGen] `sret` args should always point to the `alloca` AS, so use that (PR #114062)

@@ -1672,10 +1672,11 @@ CodeGenTypes::GetFunctionType(const CGFunctionInfo &FI) { // Add type for sret argument. if (IRFunctionArgs.hasSRetArg()) { -QualType Ret = FI.getReturnType(); -unsigned AddressSpace = CGM.getTypes().getTargetAddressSpace(Ret); +auto Ad

[clang] [clang][Driver][HIP] Add support for mixing AMDGCNSPIRV & concrete `offload-arch`s. (PR #113509)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/113509 >From 4a18bbc256051f30805620f65a4db037ea2fe96c Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Thu, 24 Oct 2024 01:14:28 +0100 Subject: [PATCH 1/2] Add support for mixing AMDGCNSPIRV & concrete `offload-arch`s.

[clang] [clang][Driver][HIP] Add support for mixing AMDGCNSPIRV & concrete `offload-arch`s. (PR #113509)

https://github.com/AlexVlx edited https://github.com/llvm/llvm-project/pull/113509 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][Driver][HIP] Add support for mixing AMDGCNSPIRV & concrete `offload-arch`s. (PR #113509)

https://github.com/AlexVlx commented: > So, I'm thinking that SPIR-V here fits better as a triple. I've been wanting > to generalize the `--offload` option to behave more like `-fopenmp-targets`. > I.e. we would have `--offload=spirv64-amd-amdhsa,amdgcn-amd-amdhsa > -Xarch_device_amdgcn-amd-am

[clang] [clang][Driver][HIP] Add support for mixing AMDGCNSPIRV & concrete `offload-arch`s. (PR #113509)

AlexVlx wrote: > > We don't use `offload` at the moment, that's for HIPSPV. Of course, future, > > fancy work is more than welcome, but this merely slots into the existing > > infra and current use cases. > > I'm not a huge fan of smuggling what is essentially a Toolchain behind what > was in

[clang] [clang][CodeGen][OpenCL] Fix `alloca` handling & `sret`when compiling for (PR #113930)

@@ -1648,6 +1648,8 @@ CodeGenTypes::GetFunctionType(const CGFunctionInfo &FI) { // Add type for sret argument. if (IRFunctionArgs.hasSRetArg()) { QualType Ret = FI.getReturnType(); +if (CGM.getLangOpts().OpenCL) + Ret = getContext().getAddrSpaceQualType(Ret, La

[clang] [clang][CodeGen][OpenCL] Fix `alloca` handling & `sret`when compiling for (PR #113930)

@@ -108,11 +108,15 @@ RawAddress CodeGenFunction::CreateTempAlloca(llvm::Type *Ty, CharUnits Align, if (AllocaAddr) *AllocaAddr = Alloca; llvm::Value *V = Alloca.getPointer(); + assert((!getLangOpts().OpenCL || + CGM.getTarget().getTargetAddressSpace(getASTAl

[clang] [clang][CodeGen][OpenCL] Fix `alloca` handling & `sret`when compiling for (PR #113930)

@@ -108,11 +108,15 @@ RawAddress CodeGenFunction::CreateTempAlloca(llvm::Type *Ty, CharUnits Align, if (AllocaAddr) *AllocaAddr = Alloca; llvm::Value *V = Alloca.getPointer(); + assert((!getLangOpts().OpenCL || + CGM.getTarget().getTargetAddressSpace(getASTAl

[clang] [clang][Driver][HIP] Add support for mixing AMDGCNSPIRV & concrete `offload-arch`s. (PR #113509)

https://github.com/AlexVlx created https://github.com/llvm/llvm-project/pull/113509 This removes the temporary ban on mixing AMDGCN flavoured SPIR-V and concrete targets (e.g. `gfx900`) in the same HIPAMD compilation. This is done primarily by tweaking the effective / observable triple when th

[clang] [clang][Driver][HIP] Add support for mixing AMDGCNSPIRV & concrete `offload-arch`s. (PR #113509)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/113509 >From 4a18bbc256051f30805620f65a4db037ea2fe96c Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Thu, 24 Oct 2024 01:14:28 +0100 Subject: [PATCH 1/2] Add support for mixing AMDGCNSPIRV & concrete `offload-arch`s.

[clang] [clang-tools-extra] [Clang] Use TargetInfo when deciding is an address space is compatible (PR #115777)

AlexVlx wrote: > For AMDGPU and NVPTX, pointers are allowed to drop their address spaces > transparently. So, `void AS(3) *` can convert to `void *`. Languages like > CUDA and SYCL and HIP use these 'language' address spaces to describe exactly > this, but my assertion is that it's more of a f

[clang] [clang][CodeGen] `sret` args should always point to the `alloca` AS, so use that (PR #114062)

AlexVlx wrote: Gentle ping - I'd like to progress this in one form or another (target hook or extending indirect to carry an AS). If there are other ideas / strong preferences / over-my-dead-body objections, they'd be more than welcome. https://github.com/llvm/llvm-project/pull/114062

[clang] [clang][CodeGen] `sret` args should always point to the `alloca` AS, so use that (PR #114062)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/114062 >From d2d2d3d5db3f639aab178f9ca9a20db2842d2b65 Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Tue, 29 Oct 2024 14:20:44 + Subject: [PATCH 1/8] `sret` args should always point to the `alloca` AS, so we can

[clang] [clang-tools-extra] [Clang] Use TargetInfo when deciding is an address space is compatible (PR #115777)

AlexVlx wrote: > I could see only applying these rules to the target specific (i.e. > non-language AS's) so `AS(3) *` would convert to `*` but not `__shared__ *`. > The above example doesn't work because we consider `cuda_shared` and `AS(3)` > distinct even though they lower to the same thing

[clang] [llvm] [opt][AMDGPU] Add pass to handle AMDGCN pseudo-intrinsics target specific info), start with `llvm.amdgcn.wavefrontsize` (PR #114481)

AlexVlx wrote: > Mechanically, this pass can be replaced with trivial handling of the > intrinsic in AMDGPUInstCombineIntrinsic; we don't need a new module pass. As > inserted into the pipeline here, this does not have any advantage over > handling it directly in instcombine. Perhaps, except

[clang] [llvm] [opt][AMDGPU] Add pass to handle AMDGCN pseudo-intrinsics target specific info), start with `llvm.amdgcn.wavefrontsize` (PR #114481)

AlexVlx wrote: > We do not want or need a new pass to handle this. This is not a fix to the > structural issue of wavesize. The problem is there is no such thing as a "no > wavesize" IR. There is only wave32 or wave64. Querying the target gives the > wrong answer for faux "generic" IR. Throwin

[clang] [llvm] [opt][AMDGPU] Add pass to handle AMDGCN pseudo-intrinsics target specific info), start with `llvm.amdgcn.wavefrontsize` (PR #114481)

AlexVlx wrote: > Just adding this to the pass pipeline where it is is no better than just > doing it in instcombine, which is the natural place to do this. This patch, > like instcombine, still has the problem that we don't know if we're producing > the final code. We could just turn this off

[clang] [llvm] [opt][AMDGPU] Add pass to handle AMDGCN pseudo-intrinsics target specific info), start with `llvm.amdgcn.wavefrontsize` (PR #114481)

AlexVlx wrote: > > Faux "generic" IR sounds like a problematic concept, do you have an example? > > It's what `libc` and the ROCm DeviceLibs do, compile or IR without `-mcpu` > and don't use any target specific attributes or intrinsics, then link it into > a TU later when the target is known.

[clang] [llvm] [opt][AMDGPU] Add pass to handle AMDGCN pseudo-intrinsics target specific info), start with `llvm.amdgcn.wavefrontsize` (PR #114481)

@@ -0,0 +1,49 @@ +//===- AMDGPUExpandPseudoIntrinsics.cpp - Pseudo Intrinsic Expander Pass --===// +// +// 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: Apa

[clang] [llvm] [opt][AMDGPU] Add pass to handle AMDGCN pseudo-intrinsics target specific info), start with `llvm.amdgcn.wavefrontsize` (PR #114481)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/114481 >From 3ba88ce598aaab269169f0a5db5981c9a9ac8603 Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Thu, 31 Oct 2024 22:38:36 + Subject: [PATCH 1/2] Add pass to handle AMDGCN pseudo-intrinsics (abstract placehol

[clang] [llvm] [opt][AMDGPU] Add pass to handle AMDGCN pseudo-intrinsics target specific info), start with `llvm.amdgcn.wavefrontsize` (PR #114481)

@@ -0,0 +1,49 @@ +//===- AMDGPUExpandPseudoIntrinsics.cpp - Pseudo Intrinsic Expander Pass --===// +// +// 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: Apa

[clang] [llvm] [opt][AMDGPU] Add pass to handle AMDGCN pseudo-intrinsics target specific info), start with `llvm.amdgcn.wavefrontsize` (PR #114481)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/114481 >From 3ba88ce598aaab269169f0a5db5981c9a9ac8603 Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Thu, 31 Oct 2024 22:38:36 + Subject: [PATCH 1/3] Add pass to handle AMDGCN pseudo-intrinsics (abstract placehol

[clang] [llvm] [opt][AMDGPU] Add pass to handle AMDGCN pseudo-intrinsics target specific info), start with `llvm.amdgcn.wavefrontsize` (PR #114481)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/114481 >From 3ba88ce598aaab269169f0a5db5981c9a9ac8603 Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Thu, 31 Oct 2024 22:38:36 + Subject: [PATCH 1/4] Add pass to handle AMDGCN pseudo-intrinsics (abstract placehol

[clang] [llvm] [opt][AMDGPU] Add pass to handle AMDGCN pseudo-intrinsics target specific info), start with `llvm.amdgcn.wavefrontsize` (PR #114481)

https://github.com/AlexVlx edited https://github.com/llvm/llvm-project/pull/114481 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][HIP] Deprecate the AMDGCN_WAVEFRONT_SIZE macros (PR #112849)

AlexVlx wrote: > > CI is red but it seems to be some weird Windows failures. Ideally if the > > builtin / intrinsic is the way to go I'd like that to be folded much > > earlier because it prevents loop unrolling for cases like SIMT scan / > > reduce. #114481 should deal with this @arsenm @jhu

[clang] [llvm] [opt][AMDGPU] Add pass to handle AMDGCN pseudo-intrinsics target specific info), start with `llvm.amdgcn.wavefrontsize` (PR #114481)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/114481 >From 3ba88ce598aaab269169f0a5db5981c9a9ac8603 Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Thu, 31 Oct 2024 22:38:36 + Subject: [PATCH] Add pass to handle AMDGCN pseudo-intrinsics (abstract placeholders

[clang] [llvm] [opt][AMDGPU] Add pass to handle AMDGCN pseudo-intrinsics target specific info), start with `llvm.amdgcn.wavefrontsize`. (PR #114481)

https://github.com/AlexVlx created https://github.com/llvm/llvm-project/pull/114481 Pseudo-intrinsics are a mechanism for conveying that some target specific constant info / quantity exists, without inducing AST mutation based on said quantity. They enable making e.g. control flow decisions in

[clang] [Clang][NFC] Remove incorrect SYCL tests (PR #109182)

AlexVlx wrote: > > Instead of removing the test case altogether, does it not suffice to remove > > the SYCL reference / SYCL specific flag, which I interpret as the problem > > being addressed? SYCL per se is not a target, but rather a language? > > Apologies if I'm missing something. > > I t

[clang] [llvm] [SPIRV][RFC] Rework / extend support for memory scopes (PR #106429)

@@ -766,8 +766,19 @@ static void EmitAtomicOp(CodeGenFunction &CGF, AtomicExpr *Expr, Address Dest, // LLVM atomic instructions always have synch scope. If clang atomic // expression has no scope operand, use default LLVM synch scope. if (!ScopeModel) { +llvm::SyncSc

[clang] [clang][CodeGen][SPIR-V] Fix incorrect SYCL usage, implement missing interface (PR #109415)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/109415 >From 75ca598c7e8a583545f50ee2c526556df261cc7f Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Fri, 20 Sep 2024 13:25:49 +0100 Subject: [PATCH 1/2] Implement `getGlobalVarAddressSpace` for SPIR-V; stop using SY

[clang] [llvm] [SPIRV][RFC] Rework / extend support for memory scopes (PR #106429)

https://github.com/AlexVlx closed https://github.com/llvm/llvm-project/pull/106429 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [SPIRV][RFC] Rework / extend support for memory scopes (PR #106429)

AlexVlx wrote: I've created for the (potential) Translator work. https://github.com/llvm/llvm-project/pull/106429 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.l

[clang] [llvm] [SPIRV][RFC] Rework / extend support for memory scopes (PR #106429)

AlexVlx wrote: Thank you ever so much for the review @VyacheslavLevytskyy! I will create a PR for the Translator as well, since there's some handling missing there; I will refer to it here for future readers. Final check: are you OK with the OpenCL changes @yxsamliu? https://github.com/llvm/l

[clang] [llvm] [SPIRV][RFC] Rework / extend support for memory scopes (PR #106429)

@@ -766,8 +766,19 @@ static void EmitAtomicOp(CodeGenFunction &CGF, AtomicExpr *Expr, Address Dest, // LLVM atomic instructions always have synch scope. If clang atomic // expression has no scope operand, use default LLVM synch scope. if (!ScopeModel) { +llvm::SyncSc

[clang] [lld] [llvm] [mlir] [IR] Introduce `T` to `DataLayout` to represent flat address space if a target supports it (PR #108786)

AlexVlx wrote: > I am personally not opposed to the DL solution, but I guess it's a big change > that feels too much for me to approve. I'm also worried the "flat" concept is > a special case of something more generic and we should instead define that. > E.g., In reply to your question above

[clang] [clang][CodeGen][SPIR-V] Fix incorrect SYCL usage, implement missing interface (PR #109415)

https://github.com/AlexVlx commented: > Are there any tests available to check this behavior? The reworked tests do verify / rely on this behaviour, but I can add an individual test for both vanilla and AMDGCN flavoured SPIR-V, if that is preferred (might be better anyway). https://github.com

[clang] [clang][CodeGen][SPIR-V] Fix incorrect SYCL usage, implement missing interface (PR #109415)

https://github.com/AlexVlx edited https://github.com/llvm/llvm-project/pull/109415 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][CodeGen][SPIR-V] Fix incorrect SYCL usage, implement missing interface (PR #109415)

https://github.com/AlexVlx closed https://github.com/llvm/llvm-project/pull/109415 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [cuda][[HIP] `__constant__` should imply constant (PR #110182)

AlexVlx wrote: > Well, it's certainly used that way in existing CUDA code and it's been around > forever: Here are few random examples: > > * from both 10 years ago: > > https://stackoverflow.com/questions/20535683/cuda-5-5-cudamemcpytosymbol-constant-and-out-of-scope-error > * fairly recent

[clang] [cuda][[HIP] `__constant__` should imply constant (PR #110182)

https://github.com/AlexVlx created https://github.com/llvm/llvm-project/pull/110182 Currently, `__constant__` variables do not get unconditionally marked as `constant` in IR, which seems a bit odd given their definition. This is generally inconsequential for NVPTX/AMDGPU, since said variables

[clang] [cuda][[HIP] `__constant__` should imply constant (PR #110182)

AlexVlx wrote: > `__constant__` may not necessarily be `const` for IR purposes. I.e. IR may > not rely on the 'known' values, as seen in IR, as the data may actually be > populated by the host via CUDA API calls `cudaMemcpyToSymbol` before the GPU > kernel launch. But since this is marked `ex

[clang] [cuda][[HIP] `__constant__` should imply constant (PR #110182)

AlexVlx wrote: > > `__constant__` may not necessarily be `const` for IR purposes. I.e. IR may > > not rely on the 'known' values, as seen in IR, as the data may actually be > > populated by the host via CUDA API calls `cudaMemcpyToSymbol` before the > > GPU kernel launch. > > But since this i

[clang] [llvm] [cuda][HIP] `__constant__` should imply constant (PR #110182)

https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/110182 >From af1adfafaa09bc7992cf9aaf34a6121cf2d56d5b Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Thu, 26 Sep 2024 04:16:52 +0100 Subject: [PATCH 1/3] Mark globals as `constant` if they have been annotated with `_

[clang] [llvm] [cuda][HIP] `__constant__` should imply constant (PR #110182)

https://github.com/AlexVlx closed https://github.com/llvm/llvm-project/pull/110182 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [cuda][[HIP] `__constant__` should imply constant (PR #110182)

AlexVlx wrote: @yxsamliu beat me to it. The problem here is that the example illustrates language level const on a variable with internal linkage (which is mandatory for `__constant__` variables in non-RDC compilation AFAICT from 17.5.24.1) and we don't set externally_initialized on that, whic

[clang] [cuda][HIP] `__constant__` should imply constant (PR #110182)

https://github.com/AlexVlx edited https://github.com/llvm/llvm-project/pull/110182 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

<    1   2   3   4   5   6   7   >