https://github.com/Pierre-vh review_requested
https://github.com/llvm/llvm-project/pull/65715
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Pierre-vh wrote:
> Is this dropping read support?
Yes, it's dropping everything
https://github.com/llvm/llvm-project/pull/65715
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Pierre-vh review_requested
https://github.com/llvm/llvm-project/pull/65715
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Pierre-vh created
https://github.com/llvm/llvm-project/pull/81718
The dot is too confusing for tools. Output temporaries would have
'10.3-generic' so tools could parse it as an extension, device libs & the
associated clang driver logic are also confused by the dot.
After di
Pierre-vh wrote:
> > Sorry, I should have clearly mentioned that. Yes, it is for my followup
> > change #80908. In #80908, we changed the type of LLVM builtin but kept the
> > corresponding clang builtin unchanged to avoid breaking existing uses.
>
> Don't see how that could be related; you ca
https://github.com/Pierre-vh closed
https://github.com/llvm/llvm-project/pull/81718
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Pierre-vh edited
https://github.com/llvm/llvm-project/pull/79236
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Pierre-vh commented:
I also agree with Jay, can't this go in InsertWaitCnt? Why does it have to go
in SIMemoryLegalizer instead?
If it has to stay here, fine, but is it possible to merge some code with
SIInsertWaitCnt in a common helper somewhere?
https://github.com/llvm/ll
@@ -167,6 +167,10 @@ def FeatureCuMode : SubtargetFeature<"cumode",
"Enable CU wavefront execution mode"
>;
+def FeaturePreciseMemory
Pierre-vh wrote:
I think you just need to add something like this in `AMDGPU.cpp` in
`getAMDGPUTargetFeatures`
```
if (A
@@ -603,14 +626,69 @@ class SIGfx12CacheControl : public SIGfx11CacheControl {
SIAtomicAddrSpace AddrSpace, SIMemOp Op,
bool IsVolatile,
bool IsNonTemporal) const o
@@ -603,14 +626,69 @@ class SIGfx12CacheControl : public SIGfx11CacheControl {
SIAtomicAddrSpace AddrSpace, SIMemOp Op,
bool IsVolatile,
bool IsNonTemporal) const o
@@ -603,14 +626,69 @@ class SIGfx12CacheControl : public SIGfx11CacheControl {
SIAtomicAddrSpace AddrSpace, SIMemOp Op,
bool IsVolatile,
bool IsNonTemporal) const o
@@ -2378,6 +2456,221 @@ bool
SIGfx12CacheControl::enableVolatileAndOrNonTemporal(
return Changed;
}
+bool SIGfx6CacheControl ::handleNonAtomicForPreciseMemory(
+MachineBasicBlock::iterator &MI) {
+ assert(MI->mayLoadOrStore());
+
+ MachineInstr &Inst = *MI;
+ AMDGPU:
@@ -2378,6 +2456,221 @@ bool
SIGfx12CacheControl::enableVolatileAndOrNonTemporal(
return Changed;
}
+bool SIGfx6CacheControl ::handleNonAtomicForPreciseMemory(
+MachineBasicBlock::iterator &MI) {
+ assert(MI->mayLoadOrStore());
+
+ MachineInstr &Inst = *MI;
+ AMDGPU:
https://github.com/Pierre-vh requested changes to this pull request.
Did you try to move this to SIInsertWaitCnt, as suggested?
https://github.com/llvm/llvm-project/pull/79236
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.o
https://github.com/Pierre-vh edited
https://github.com/llvm/llvm-project/pull/79236
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -355,6 +356,18 @@ class SICacheControl {
MachineBasicBlock::iterator &MI) const {
return false;
}
+
+public:
+ // The following is for supporting precise memory mode. When the option
+ // amdgpu-precise-memory is enabled, an s_waitc
@@ -167,6 +167,10 @@ def FeatureCuMode : SubtargetFeature<"cumode",
"Enable CU wavefront execution mode"
>;
+def FeaturePreciseMemory
Pierre-vh wrote:
The extra overhead is just 3 lines in `clang/lib/Driver/ToolChains/AMDGPU.cpp`,
it's negligible.
We don't
@@ -167,6 +167,10 @@ def FeatureCuMode : SubtargetFeature<"cumode",
"Enable CU wavefront execution mode"
>;
+def FeaturePreciseMemory
Pierre-vh wrote:
It's only called once per run by the driver, yes
We already do this for wavefrontsize64, and pretty much
@@ -167,6 +167,10 @@ def FeatureCuMode : SubtargetFeature<"cumode",
"Enable CU wavefront execution mode"
>;
+def FeaturePreciseMemory
Pierre-vh wrote:
Just remove `m_amdgpu_Features_Group` from your option's `SimpleMFlag`, follow
the same pattern as `wavef
Pierre-vh wrote:
> Thanks for the comments @arsenm @yxsamliu @b-sumner.
>
> By approaching a similar solution, do you mean MMRAs (#78569) ?
>
> If so, should I rebase/adapt my patch to the MMRA PR? Or will this PR be
> redundant and needs closing?
>
> @yxsamliu These concise names look good t
@@ -0,0 +1,1037 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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: Apach
@@ -0,0 +1,1037 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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: Apach
@@ -0,0 +1,1037 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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: Apach
@@ -0,0 +1,1037 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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: Apach
@@ -0,0 +1,1037 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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: Apach
@@ -0,0 +1,1037 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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: Apach
@@ -0,0 +1,1037 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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: Apach
@@ -0,0 +1,1037 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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: Apach
@@ -0,0 +1,1037 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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: Apach
@@ -0,0 +1,1037 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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: Apach
@@ -0,0 +1,1037 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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: Apach
@@ -0,0 +1,1037 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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: Apach
@@ -0,0 +1,1037 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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: Apach
@@ -0,0 +1,1037 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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: Apach
@@ -0,0 +1,1037 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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: Apach
@@ -0,0 +1,1037 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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: Apach
@@ -0,0 +1,1037 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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: Apach
@@ -0,0 +1,1037 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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: Apach
https://github.com/Pierre-vh edited
https://github.com/llvm/llvm-project/pull/93362
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -992,6 +993,8 @@ void AMDGPUPassConfig::addIRPasses() {
if (isPassEnabled(EnableImageIntrinsicOptimizer))
addPass(createAMDGPUImageIntrinsicOptimizerPass(&TM));
+ addPass(createExpandVariadicsPass(ExpandVariadicsMode::Lowering));
Pierre-vh wrote:
Pl
https://github.com/Pierre-vh approved this pull request.
LGTM if a kill switch is added, I would wait a day more before landing in case
anyone else has concerns
https://github.com/llvm/llvm-project/pull/93362
___
cfe-commits mailing list
cfe-commits@l
https://github.com/Pierre-vh approved this pull request.
https://github.com/llvm/llvm-project/pull/93875
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -18319,6 +18320,26 @@ Value *CodeGenFunction::EmitHLSLBuiltinExpr(unsigned
BuiltinID,
return nullptr;
}
+void CodeGenFunction::AddAMDGCNAddressSpaceMMRA(llvm::Instruction *Inst,
+llvm::Value *ASMask) {
+ constexpr const ch
https://github.com/Pierre-vh edited
https://github.com/llvm/llvm-project/pull/78572
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Pierre-vh edited
https://github.com/llvm/llvm-project/pull/78572
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -18319,6 +18320,26 @@ Value *CodeGenFunction::EmitHLSLBuiltinExpr(unsigned
BuiltinID,
return nullptr;
}
+void CodeGenFunction::AddAMDGCNAddressSpaceMMRA(llvm::Instruction *Inst,
+llvm::Value *ASMask) {
+ constexpr const ch
@@ -69,6 +69,7 @@ BUILTIN(__builtin_amdgcn_iglp_opt, "vIi", "n")
BUILTIN(__builtin_amdgcn_s_dcache_inv, "v", "n")
BUILTIN(__builtin_amdgcn_buffer_wbinvl1, "v", "n")
BUILTIN(__builtin_amdgcn_fence, "vUicC*", "n")
+BUILTIN(__builtin_amdgcn_masked_fence, "vUiUicC*", "n")
-
Pierre-vh wrote:
I changed it so it's one or more string arguments:
```
__builtin_amdgcn_masked_fence(__ATOMIC_SEQ_CST, "workgroup", "local", "global")
```
I'm now wondering if adding a new builtin is needed at all, or if it should
just be part of the original builtin? It's an additive change.
https://github.com/Pierre-vh edited
https://github.com/llvm/llvm-project/pull/78572
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Pierre-vh edited
https://github.com/llvm/llvm-project/pull/78572
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -18365,6 +18366,28 @@ Value *CodeGenFunction::EmitHLSLBuiltinExpr(unsigned
BuiltinID,
return nullptr;
}
+void CodeGenFunction::AddAMDGCNFenceAddressSpaceMMRA(llvm::Instruction *Inst,
+ const CallExpr *E) {
+ constexpr
@@ -4408,6 +4409,42 @@ Target-Specific Extensions
Clang supports some language features conditionally on some targets.
+AMDGPU Language Extensions
+--
+
+__builtin_amdgcn_fence
+^^
+
+``__builtin_amdgcn_fence`` emits a fence.
+
+* `
@@ -4408,6 +4409,42 @@ Target-Specific Extensions
Clang supports some language features conditionally on some targets.
+AMDGPU Language Extensions
+--
+
+__builtin_amdgcn_fence
+^^
+
+``__builtin_amdgcn_fence`` emits a fence.
+
+* `
@@ -678,6 +680,54 @@ class SIMemoryLegalizer final : public MachineFunctionPass
{
bool runOnMachineFunction(MachineFunction &MF) override;
};
+static std::array, 3> ASNames = {{
+{"global", SIAtomicAddrSpace::GLOBAL},
+{"local", SIAtomicAddrSpace::LDS},
+{"image
Pierre-vh wrote:
@arsenm Should we use `image` or `private`?
We could allow both in the frontend, and only use `private` as the canonical
MMRA.
https://github.com/llvm/llvm-project/pull/78572
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
htt
Pierre-vh wrote:
> > @arsenm Should we use `image` or `private`? We could allow both in the
> > frontend, and only use `private` as the canonical MMRA.
>
> I don't understand why image would imply private. I would just keep at as
> private throughout
I thought image memory = private. It's unc
Pierre-vh wrote:
> > I thought image memory = private. It's unclear to me, what AS does OpenCL
> > IMAGE memory map to in our backend? (But otherwise, yes, MMRA should just
> > have the backend names, the mapping of the OpenCL IMAGE to a backend AS
> > should be in the device-lib)
>
> Images
Pierre-vh wrote:
> > Then I guess the MMRA should just have "global" and "local" for now, we can
> > always add more later if needed. What do you think?
>
> Yes, we don't have specific image counters. They are just vcmnt
Diff has been updated with those changes
https://github.com/llvm/llvm-pr
https://github.com/Pierre-vh closed
https://github.com/llvm/llvm-project/pull/78572
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Pierre-vh wrote:
@shiltian Please also remove `warn_drv_amdgpu_cov6` - it's a warning I added
while v6 was being worked on.
Now that it's supported by the stack we can remove it.
https://github.com/llvm/llvm-project/pull/118515
___
cfe-commits mailing
Pierre-vh wrote:
I'm trying to understand this. Is the function being changed a generic util
called by multiple builtins, and this change is just to make `one-as` exclusive
to the OpenCL variant of those builtins ?
Can an identical builtin have different behavior depending on the input
languag
https://github.com/Pierre-vh approved this pull request.
Ah, that makes sense. It's surprising it wasn't like that in the first place
https://github.com/llvm/llvm-project/pull/120095
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists
Pierre-vh wrote:
> > Ah, that makes sense. It's surprising it wasn't like that in the first place
>
> But can we now get rid of the -one-as sync scopes and replace them with MMRAs?
MMRAs are droppable so not currently suited to replace syncscopes like that,
but it's a goal.
As part of the Vul
Pierre-vh wrote:
I'll get it tested internally ASAP. I wasn't confident in the driver changes so
I was waiting for more feedback before doing it
I'll update once I get results
https://github.com/llvm/llvm-project/pull/128509
___
cfe-commits mailing li
Pierre-vh wrote:
@shiltian PSDB passed, is it enough to land?
https://github.com/llvm/llvm-project/pull/128509
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Pierre-vh closed
https://github.com/llvm/llvm-project/pull/128509
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Pierre-vh edited
https://github.com/llvm/llvm-project/pull/128509
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Pierre-vh updated
https://github.com/llvm/llvm-project/pull/128509
>From e580bbe66a5d65e90051cb0906b87478341696e6 Mon Sep 17 00:00:00 2001
From: pvanhout
Date: Mon, 24 Feb 2025 14:21:49 +0100
Subject: [PATCH 1/5] [clang][AMDGPU] Enable module splitting by default
The default
@@ -3368,7 +3368,8 @@ bool AMDGPUInstructionSelector::selectG_INSERT_VECTOR_ELT(
}
bool AMDGPUInstructionSelector::selectBufferLoadLds(MachineInstr &MI) const {
- assert(!AMDGPU::isGFX12Plus(STI));
+ if (!Subtarget->hasLDSBufferLoad())
Pierre-vh wrote:
Can
@@ -10104,7 +10104,8 @@ SDValue SITargetLowering::LowerINTRINSIC_VOID(SDValue
Op,
case Intrinsic::amdgcn_raw_ptr_buffer_load_lds:
case Intrinsic::amdgcn_struct_buffer_load_lds:
case Intrinsic::amdgcn_struct_ptr_buffer_load_lds: {
-assert(!AMDGPU::isGFX12Plus(*Subtarg
https://github.com/Pierre-vh approved this pull request.
https://github.com/llvm/llvm-project/pull/133164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,11 @@
+// Check that if we are compiling with fgpu-rdc amdgpu-enable-hipstdpar is not
+// passed to CC1, to avoid eager, per TU, removal of potentially accessible
+// functions.
+
+// RUN: %clang -### --hipstdpar --offload-arch=gfx906 %s -nogpulib -nogpuinc \
+// RUN:
@@ -883,6 +883,12 @@ void
AMDGPUTargetMachine::registerPassBuilderCallbacks(PassBuilder &PB) {
PB.registerFullLinkTimeOptimizationLastEPCallback(
[this](ModulePassManager &PM, OptimizationLevel Level) {
+// When we are using -fgpu-rdc, we can onky run accelera
@@ -0,0 +1,11 @@
+// Check that if we are compiling with fgpu-rdc amdgpu-enable-hipstdpar is not
+// passed to CC1, to avoid eager, per TU, removal of potentially accessible
+// functions.
+
+// RUN: %clang -### --hipstdpar --offload-arch=gfx906 %s -nogpulib -nogpuinc \
+// RUN:
Juan Manuel Martinez =?utf-8?q?Caamaño?= ,
Juan Manuel Martinez =?utf-8?q?Caamaño?=
Message-ID:
In-Reply-To:
@@ -0,0 +1,45 @@
+; RUN: split-file %s %t
+;
+; RUN: not --crash llc -mtriple=amdgcn -mcpu=gfx1100 %t/struct.ll 2>&1 |
FileCheck --ignore-case %s
+; RUN: not --crash ll
Pierre-vh wrote:
Can you please document it in the AMDGPUUsage table as well?
https://github.com/llvm/llvm-project/pull/137425
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Pierre-vh updated
https://github.com/llvm/llvm-project/pull/128509
>From cae772441c0d87a017f5cc2cb0b9c970c6b7fcde Mon Sep 17 00:00:00 2001
From: pvanhout
Date: Mon, 24 Feb 2025 14:21:49 +0100
Subject: [PATCH 1/4] [clang][AMDGPU] Enable module splitting by default
The default
https://github.com/Pierre-vh updated
https://github.com/llvm/llvm-project/pull/128509
>From e580bbe66a5d65e90051cb0906b87478341696e6 Mon Sep 17 00:00:00 2001
From: pvanhout
Date: Mon, 24 Feb 2025 14:21:49 +0100
Subject: [PATCH 1/4] [clang][AMDGPU] Enable module splitting by default
The default
https://github.com/Pierre-vh updated
https://github.com/llvm/llvm-project/pull/128509
>From cae772441c0d87a017f5cc2cb0b9c970c6b7fcde Mon Sep 17 00:00:00 2001
From: pvanhout
Date: Mon, 24 Feb 2025 14:21:49 +0100
Subject: [PATCH 1/2] [clang][AMDGPU] Enable module splitting by default
The default
https://github.com/Pierre-vh updated
https://github.com/llvm/llvm-project/pull/128509
>From cae772441c0d87a017f5cc2cb0b9c970c6b7fcde Mon Sep 17 00:00:00 2001
From: pvanhout
Date: Mon, 24 Feb 2025 14:21:49 +0100
Subject: [PATCH 1/3] [clang][AMDGPU] Enable module splitting by default
The default
https://github.com/Pierre-vh created
https://github.com/llvm/llvm-project/pull/128509
The default number of partitions is the number of cores on the machine with a
cap at 16, as going above 16 is unlikely to be useful in the common case.
Adds a flto-partitions option to override the number of
@@ -708,6 +712,34 @@ void amdgpu::getAMDGPUTargetFeatures(const Driver &D,
options::OPT_m_amdgpu_Features_Group);
}
+static unsigned GetFullLTOPartitions(const Driver &D, const ArgList &Args) {
+ const Arg *A = Args.getLastArg(options::OPT_flto_par
@@ -0,0 +1,45 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --version 5
+// RUN: %clang_cc1 -O0 -cl-std=CL2.0 -triple amdgcn-amd-amdhsa -target-cpu
gfx942 \
+// RUN: %s -emit-llvm -o - | FileCheck %s
+
+// REQUIRES: amdgpu-register
https://github.com/Pierre-vh updated
https://github.com/llvm/llvm-project/pull/141053
>From 68db9fad42369be31d935257a2d80962a4018892 Mon Sep 17 00:00:00 2001
From: pvanhout
Date: Thu, 22 May 2025 14:13:54 +0200
Subject: [PATCH 1/3] [clang][CodeGen] Fix crash on non-natural type in
CheckAtomicA
https://github.com/Pierre-vh updated
https://github.com/llvm/llvm-project/pull/141053
>From 68db9fad42369be31d935257a2d80962a4018892 Mon Sep 17 00:00:00 2001
From: pvanhout
Date: Thu, 22 May 2025 14:13:54 +0200
Subject: [PATCH 1/2] [clang][CodeGen] Fix crash on non-natural type in
CheckAtomicA
https://github.com/Pierre-vh updated
https://github.com/llvm/llvm-project/pull/141053
>From 68db9fad42369be31d935257a2d80962a4018892 Mon Sep 17 00:00:00 2001
From: pvanhout
Date: Thu, 22 May 2025 14:13:54 +0200
Subject: [PATCH 1/4] [clang][CodeGen] Fix crash on non-natural type in
CheckAtomicA
https://github.com/Pierre-vh closed
https://github.com/llvm/llvm-project/pull/141053
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Pierre-vh updated
https://github.com/llvm/llvm-project/pull/141053
>From 68db9fad42369be31d935257a2d80962a4018892 Mon Sep 17 00:00:00 2001
From: pvanhout
Date: Thu, 22 May 2025 14:13:54 +0200
Subject: [PATCH 1/5] [clang][CodeGen] Fix crash on non-natural type in
CheckAtomicA
https://github.com/Pierre-vh created
https://github.com/llvm/llvm-project/pull/141053
In some specific scenarios, `Ptr.getElementType()` won't be a primitive
type or a vector of primitive types, and thus `getScalarSizeInBits()` returns
zero.
Use the datalayout to get the proper size of the type
Pierre-vh wrote:
* **#141053** https://app.graphite.dev/github/pr/llvm/llvm-project/141053?utm_source=stack-comment-icon";
target="_blank">https://static.graphite.dev/graphite-32x32-black.png"; alt="Graphite"
width="10px" height="10px"/> 👈 https://app.graphite.dev/github/pr/llvm/llvm-project/14
https://github.com/Pierre-vh ready_for_review
https://github.com/llvm/llvm-project/pull/141053
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Pierre-vh wrote:
* **#148627** https://app.graphite.dev/github/pr/llvm/llvm-project/148627?utm_source=stack-comment-icon";
target="_blank">https://static.graphite.dev/graphite-32x32-black.png"; alt="Graphite"
width="10px" height="10px"/> 👈 https://app.graphite.dev/github/pr/llvm/llvm-project/14
https://github.com/Pierre-vh created
https://github.com/llvm/llvm-project/pull/148627
"amdgpu-as" is way too vague and doesn't give enough context.
We may want to support it on normal atomics too, to control the synchronized
(ordered) AS.
If we do that, the name has to be less vague.
>From b16
https://github.com/Pierre-vh ready_for_review
https://github.com/llvm/llvm-project/pull/148627
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
101 - 195 of 195 matches
Mail list logo
