@@ -745,12 +745,10 @@ Let ``VT`` be a vector type and ``ET`` the element type
of ``VT``.
===
==
==
Name
https://github.com/arsenm edited
https://github.com/llvm/llvm-project/pull/113628
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,9 @@
+// REQUIRES: system-windows
arsenm wrote:
This doesn't require windows, use an explicit triple
https://github.com/llvm/llvm-project/pull/113628
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -425,6 +425,12 @@ MSVCToolChain::MSVCToolChain(const Driver &D, const
llvm::Triple &Triple,
const ArgList &Args)
: ToolChain(D, Triple, Args), CudaInstallation(D, Triple, Args),
RocmInstallation(D, Triple, Args) {
+
+ // Tell the ROCm
@@ -0,0 +1,9 @@
+// REQUIRES: system-linux
arsenm wrote:
This doesn't require linux, use an explicit triple
https://github.com/llvm/llvm-project/pull/113628
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http
@@ -0,0 +1,9 @@
+// REQUIRES: system-windows
arsenm wrote:
Also add a clang-cl test?
https://github.com/llvm/llvm-project/pull/113628
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-
arsenm wrote:
Commit title should be more specific and remove the Gerrit id
https://github.com/llvm/llvm-project/pull/113628
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/arsenm approved this pull request.
https://github.com/llvm/llvm-project/pull/114386
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,11 @@
+_CLC_OVERLOAD _CLC_DEF __CLC_GENTYPE __clc_max(__CLC_GENTYPE a,
+ __CLC_GENTYPE b) {
+ return (a > b ? a : b);
+}
+
+#ifndef __CLC_SCALAR
+_CLC_OVERLOAD _CLC_DEF __CLC_GENTYPE __clc_max(__CLC_GENTYPE a,
+
https://github.com/arsenm requested changes to this pull request.
Moving them seems fine but these should probably just be deleted. __clc_min is
equivalent to __builtin_elementwise_min etc.
I see there's a __builtin_hlsl_elementwise_clamp, but given the language prefix
it may be more abusive
arsenm 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.
> We could just turn this
https://github.com/arsenm requested changes to this pull request.
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
@@ -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
@@ -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
arsenm 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.
https://github.com/llvm/llvm-project
https://github.com/arsenm approved this pull request.
https://github.com/llvm/llvm-project/pull/115885
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -322,22 +322,26 @@ foreach( t ${LIBCLC_TARGETS_TO_BUILD} )
if ( ARCH STREQUAL spirv OR ARCH STREQUAL spirv64 )
set( build_flags -O0 -finline-hint-functions -DCLC_SPIRV )
- set( opt_flags )
+ set( clc_opt_flags )
+ # Inline CLC functions into OpenCL
https://github.com/arsenm approved this pull request.
https://github.com/llvm/llvm-project/pull/115865
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
arsenm wrote:
> @aeubanks @arsenm after looking into this in more detail, I realized that the
> `getContext` method of `MMI` is heavily used in the `AsmPrinter` to create
> symbols. Also not having it makes it harder for the `MMI` to create machine
> functions using `getOrCreateMachineFunction
@@ -774,18 +774,27 @@ class buffer_unique_ostream : public raw_svector_ostream {
// you can use
// OS << indent(6) << "more stuff";
// which has better ergonomics (and clang-formats better as well).
+//
+// If indentation is always in increments of a fixed value, you can use Sc
https://github.com/arsenm approved this pull request.
https://github.com/llvm/llvm-project/pull/109478
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
arsenm wrote:
> Nixpkgs has no intention of moving away from standalone builds.
I encourage you to acquire that intention. IMO libclc should not support the
standalone build, and this should be version locked to the exact compiler
commit. It's compiler data, not a real library
https://github
https://github.com/arsenm edited
https://github.com/llvm/llvm-project/pull/105969
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -55,7 +55,7 @@ if( LIBCLC_STANDALONE_BUILD OR CMAKE_SOURCE_DIR STREQUAL
CMAKE_CURRENT_SOURCE_DI
# Import required tools
if( NOT EXISTS ${LIBCLC_CUSTOM_LLVM_TOOLS_BINARY_DIR} )
foreach( tool IN ITEMS clang llvm-as llvm-link opt )
- find_program( LLVM_TOOL_${tool
https://github.com/arsenm commented:
The nix build should probably migrate to using the non-standalone build
https://github.com/llvm/llvm-project/pull/105969
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman
arsenm wrote:
> So it should be built along with the core of LLVM? Also, we package LLVM per
> version per subproject.
Yes, it should be built along with the core (but doesn't need to ship in the
same package as the core).
https://github.com/llvm/llvm-project/pull/105969
__
https://github.com/arsenm approved this pull request.
https://github.com/llvm/llvm-project/pull/108853
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/arsenm closed
https://github.com/llvm/llvm-project/pull/107598
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
arsenm wrote:
Superseded by #108853
https://github.com/llvm/llvm-project/pull/107598
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/arsenm approved this pull request.
LGTM, but like I mentioned on #107598, it would be good if there was a test
that requires the argument check, and the return check isn't sufficient
https://github.com/llvm/llvm-project/pull/108853
___
arsenm wrote:
> If we already have per-function metadata, I'm wondering how difficult it
> would be to put this handling in the linker. AFAIK there's already handling
> for `call-graph-profile` which can inform the linker of the call-graph, so we
> could potentially just walk that graph, find
https://github.com/arsenm approved this pull request.
https://github.com/llvm/llvm-project/pull/109894
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -706,6 +706,12 @@ Unless specified otherwise operation(±0) = ±0 and
operation(±infinity) = ±in
representable values for the
signed/unsigned integer type.
T __builtin_elementwise_sub_sat(T x, T y) return the difference of x and
arsenm wrote:
If it's not legal for it to be marked as constant, it's also not legal to use
constant address space
https://github.com/llvm/llvm-project/pull/110182
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
@@ -690,23 +690,46 @@ static RValue emitLibraryCall(CodeGenFunction &CGF, const
FunctionDecl *FD,
const CallExpr *E, llvm::Constant *calleeValue) {
CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, E);
CGCallee callee = CGCallee::forDirect(call
@@ -4377,7 +4377,7 @@
AMDGPUInstructionSelector::selectGlobalSAddr(MachineOperand &Root) const {
// instructions to perform VALU adds with immediates or inline
literals.
unsigned NumLiterals =
!TII.isInlineConstant(APInt(32, ConstOffset & 0xfff
@@ -1806,7 +1806,7 @@ bool AMDGPUDAGToDAGISel::SelectGlobalSAddr(SDNode *N,
// instructions to perform VALU adds with immediates or inline literals.
unsigned NumLiterals =
!TII->isInlineConstant(APInt(32, COffsetVal & 0x)) +
- !TII->isInli
arsenm wrote:
> @aeubanks It's not impossible to separate them completely. `MCContext` is
> needed during initialization and finalization of the
> `MachineModuleInfoWrapperPass` (and its new pass manager variant) to set the
> diagnostics handler.
>
> In theory, you can just pass the context t
@@ -1122,6 +1122,26 @@ define void @fastMathFlagsForArrayCalls([2 x float] %f,
[2 x double] %d1, [2 x <
ret void
}
+declare { float, float } @fmf_struct_f32()
+declare { double, double } @fmf_struct_f64()
+declare { <4 x double>, <4 x double> } @fmf_struct_v4f64()
+
+; CHEC
arsenm wrote:
> * Move the MC emission functions in `TargetMachine` to `LLVMTargetMachine`.
> With the changes in this PR, we explicitly assume in both
> `addPassesToEmitFile` and `addPassesToEmitMC` that the `TargetMachine` is an
> `LLVMTargetMachine`; Hence it does not make sense for these f
arsenm wrote:
> With the constrained intrinsics the default is safe because optimizations
> don't recognize the constrained intrinsic and thus don't know how to optimize
> it. If we instead rely on the strictfp attribute then we'll need possibly
> thousands of checks for this attribute, we'll
https://github.com/arsenm approved this pull request.
https://github.com/llvm/llvm-project/pull/110032
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1556,7 +1557,7 @@ class RecordVal {
bool IsUsed = false;
/// Reference locations to this record value.
- SmallVector ReferenceLocs;
+ mutable SmallVector ReferenceLocs;
arsenm wrote:
Is this removed in later patches?
https://github.com/llvm/llvm-p
@@ -273,6 +273,74 @@ void test_builtin_elementwise_min(int i, short s, double
d, float4 v, int3 iv, u
// expected-error@-1 {{1st argument must be a vector, integer or floating
point type (was '_Complex float')}}
}
+void test_builtin_elementwise_maximum(int i, short s, floa
@@ -1,56 +0,0 @@
-; This test aims to check ability to support "Arithmetic with Overflow"
intrinsics
arsenm wrote:
This one is testing codegenprepare as part of the normal codegen pipeline, so
this one is fine. The other case was a full optimization pipeline +
@@ -54,14 +54,14 @@ static std::string computeDataLayout(const Triple &TT) {
// memory model used for graphics: PhysicalStorageBuffer64. But it shouldn't
// mean anything.
if (Arch == Triple::spirv32)
-return "e-p:32:32-i64:64-v16:16-v24:32-v32:32-v48:64-"
-
@@ -1,56 +0,0 @@
-; This test aims to check ability to support "Arithmetic with Overflow"
intrinsics
arsenm wrote:
Not sure what the problem is with this test, but it's already covered by
another?
https://github.com/llvm/llvm-project/pull/110695
_
https://github.com/arsenm approved this pull request.
https://github.com/llvm/llvm-project/pull/110506
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/arsenm approved this pull request.
https://github.com/llvm/llvm-project/pull/110198
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1,56 +0,0 @@
-; This test aims to check ability to support "Arithmetic with Overflow"
intrinsics
arsenm wrote:
That is not the nature of this kind of test
https://github.com/llvm/llvm-project/pull/110695
___
cfe-c
@@ -54,14 +54,14 @@ static std::string computeDataLayout(const Triple &TT) {
// memory model used for graphics: PhysicalStorageBuffer64. But it shouldn't
// mean anything.
if (Arch == Triple::spirv32)
-return "e-p:32:32-i64:64-v16:16-v24:32-v32:32-v48:64-"
-
arsenm wrote:
> > I would like to avoid adding additional special properties to AS0, or
> > defining the flat concept.
>
> How can we add a new specification w/o defining it?
By not defining it in terms of flat addressing. Just make it the undesirable
address space
https://github.com/llvm/ll
@@ -66,12 +66,12 @@ NVPTXTargetInfo::NVPTXTargetInfo(const llvm::Triple &Triple,
HasFloat16 = true;
if (TargetPointerWidth == 32)
-resetDataLayout("e-p:32:32-i64:64-i128:128-v16:16-v32:32-n16:32:64");
+resetDataLayout("e-p:32:32-i64:64-i128:128-v16:16-v32:32-n16:32
arsenm wrote:
> There are targets that use a different integer to denote flat (e.g. see SPIR
> & SPIR-V). Whilst I know that there are objections to that, the fact remains
> that they had historical reason (wanted to make legacy OCL convention that
> the default is private work, and given that
arsenm wrote:
> Just to clarify, does this mean any two non-flat address space pointers
> _cannot_ alias?
This should change nothing about aliasing. The IR assumption is any address
space may alias any other
https://github.com/llvm/llvm-project/pull/108786
___
@@ -579,7 +579,7 @@ static StringRef computeDataLayout(const Triple &TT) {
"-p7:160:256:256:32-p8:128:128-p9:192:256:256:32-i64:64-v16:16-v24:32-"
"v32:32-v48:64-v96:"
"128-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64-S32-A5-"
- "G
arsenm wrote:
> Both in InferAddressSpaces, and in Attributor, you don't really care about
> whether a flat address-space exists.
Right, this is more of an undesirable address space. Optimizations don't need
to know anything about its behavior beyond that.
> In reply to your question above
@@ -357,6 +357,9 @@ class IRBuilderBase {
void setConstrainedFPCallAttr(CallBase *I) {
I->addFnAttr(Attribute::StrictFP);
+MemoryEffects ME = MemoryEffects::inaccessibleMemOnly();
arsenm wrote:
It shouldn't be necessary to touch the attributes. The
arsenm wrote:
Also it's silly that we need to do bitcode autoupgrade of "experimental"
intrinsics, but x86 started shipping with strictfp enabled in production before
they graduated. We might as well drop the experimental bit then
https://github.com/llvm/llvm-project/pull/109798
_
@@ -78,15 +78,15 @@ void MCResourceInfo::finalize(MCContext &OutContext) {
}
MCSymbol *MCResourceInfo::getMaxVGPRSymbol(MCContext &OutContext) {
- return OutContext.getOrCreateSymbol("max_num_vgpr");
+ return OutContext.getOrCreateSymbol("amdgcn.max_num_vgpr");
-
@@ -434,6 +434,15 @@ struct AAAMDAttributesFunction : public AAAMDAttributes {
indicatePessimisticFixpoint();
return;
}
+
+for (Instruction &I : instructions(F)) {
+ if (isa(I) &&
arsenm wrote:
5->3 is an illegal address space cast, bu
arsenm wrote:
> If we can't keep the constrained semantics and near-100% guarantee that no
> new exceptions will be introduced then operand bundles are not a replacement
> for the constrained intrinsics.
We would still need a call / function attribute to indicate strictfp calls, and
such call
https://github.com/arsenm approved this pull request.
I think we need more thought about how the ABI for this will work, but we need
to start somewhere
https://github.com/llvm/llvm-project/pull/102913
___
cfe-commits mailing list
cfe-commits@lists.ll
@@ -434,6 +434,15 @@ struct AAAMDAttributesFunction : public AAAMDAttributes {
indicatePessimisticFixpoint();
return;
}
+
+for (Instruction &I : instructions(F)) {
+ if (isa(I) &&
arsenm wrote:
Simple example, where the cast is still d
https://github.com/arsenm edited https://github.com/llvm/llvm-project/pull/94647
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/arsenm edited
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
arsenm wrote:
> 1. Usually (or at least AFAIK) optimization passes won't consider datalayout
> automatically,
The datalayout is a widely used global constant. There's no option of "not
considering it"
> Do you plan to go over LLVM passes adding this check?
There's nothing new to do here. T
@@ -1,56 +0,0 @@
-; This test aims to check ability to support "Arithmetic with Overflow"
intrinsics
arsenm wrote:
> Right but it's relying on a non-guaranteed maybe-optimisation firing, as far
> as I can tell.
The point is to test the optimization does work.
@@ -0,0 +1,187 @@
+//===-- amdgpuintrin.h - AMDPGU intrinsic functions
---===//
+//
+// 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
@@ -0,0 +1,187 @@
+//===-- amdgpuintrin.h - AMDPGU intrinsic functions
---===//
+//
+// 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
https://github.com/arsenm approved this pull request.
https://github.com/llvm/llvm-project/pull/110747
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1660,7 +1660,7 @@ class Record {
// this record.
SmallVector Locs;
SmallVector ForwardDeclarationLocs;
- SmallVector ReferenceLocs;
+ mutable SmallVector ReferenceLocs;
arsenm wrote:
You have the const_cast on the addition, so this is unnecessary?
@@ -0,0 +1,102 @@
+//===-- LLVMTargetMachineC.cpp
===//
+//
+// 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
@@ -1,56 +0,0 @@
-; This test aims to check ability to support "Arithmetic with Overflow"
intrinsics
arsenm wrote:
The codegen prepare behavior is still backend code to be tested. You can just
run codegenprepare as a standalone pass too (usually would have sepa
https://github.com/arsenm created
https://github.com/llvm/llvm-project/pull/115238
These were dropped in b1bcb7ca460fcd317bbc8309e14c8761bf8394e0 to
avoid some bot failures.
>From 3a5d957b5fe0d36df2273693c7c865c39715d192 Mon Sep 17 00:00:00 2001
From: Matt Arsenault
Date: Mon, 15 Jul 2024 11:4
arsenm wrote:
* **#115238** https://app.graphite.dev/github/pr/llvm/llvm-project/115238?utm_source=stack-comment-icon";
target="_blank">https://static.graphite.dev/graphite-32x32-black.png"; alt="Graphite"
width="10px" height="10px"/> 👈
* `main`
This stack of pull requests is managed by Graphi
https://github.com/arsenm ready_for_review
https://github.com/llvm/llvm-project/pull/115238
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -462,6 +462,10 @@ class LLVM_LIBRARY_VISIBILITY AMDGPUTargetInfo final :
public TargetInfo {
}
bool hasHIPImageSupport() const override { return HasImage; }
+
+ std::pair hardwareInterferenceSizes() const override {
+return std::make_pair(128, 128);
--
@@ -703,6 +715,39 @@ SDValue BPFTargetLowering::LowerSELECT_CC(SDValue Op,
SelectionDAG &DAG) const {
return DAG.getNode(BPFISD::SELECT_CC, DL, VTs, Ops);
}
+SDValue BPFTargetLowering::LowerATOMIC_LOAD(SDValue Op,
+SelectionDAG &D
@@ -703,6 +715,39 @@ SDValue BPFTargetLowering::LowerSELECT_CC(SDValue Op,
SelectionDAG &DAG) const {
return DAG.getNode(BPFISD::SELECT_CC, DL, VTs, Ops);
}
+SDValue BPFTargetLowering::LowerATOMIC_LOAD(SDValue Op,
+SelectionDAG &D
@@ -0,0 +1,76 @@
+//===-- gpuintrin.h - Generic GPU intrinsic functions
-===//
+//
+// 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
@@ -31,16 +44,118 @@ typedef hipError_t (*hipGetDeviceCount_t)(int *);
typedef hipError_t (*hipDeviceGet_t)(int *, int);
typedef hipError_t (*hipGetDeviceProperties_t)(hipDeviceProp_t *, int);
-int printGPUsByHIP() {
+extern cl::opt Verbose;
+
#ifdef _WIN32
- constexpr const
@@ -31,16 +44,118 @@ typedef hipError_t (*hipGetDeviceCount_t)(int *);
typedef hipError_t (*hipDeviceGet_t)(int *, int);
typedef hipError_t (*hipGetDeviceProperties_t)(hipDeviceProp_t *, int);
-int printGPUsByHIP() {
+extern cl::opt Verbose;
+
#ifdef _WIN32
- constexpr const
@@ -31,16 +44,118 @@ typedef hipError_t (*hipGetDeviceCount_t)(int *);
typedef hipError_t (*hipDeviceGet_t)(int *, int);
typedef hipError_t (*hipGetDeviceProperties_t)(hipDeviceProp_t *, int);
-int printGPUsByHIP() {
+extern cl::opt Verbose;
+
#ifdef _WIN32
- constexpr const
@@ -648,6 +648,17 @@ void amdgpu::Linker::ConstructJob(Compilation &C, const
JobAction &JA,
Args.MakeArgString("-plugin-opt=-mattr=" + llvm::join(Features, ",")));
}
+ if (Args.hasArg(options::OPT_stdlib))
+CmdArgs.append({"-lc", "-lm"});
+ if (Args.hasArg(opt
@@ -31,16 +44,118 @@ typedef hipError_t (*hipGetDeviceCount_t)(int *);
typedef hipError_t (*hipDeviceGet_t)(int *, int);
typedef hipError_t (*hipGetDeviceProperties_t)(hipDeviceProp_t *, int);
-int printGPUsByHIP() {
+extern cl::opt Verbose;
+
#ifdef _WIN32
- constexpr const
https://github.com/arsenm approved this pull request.
https://github.com/llvm/llvm-project/pull/113610
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,154 @@
+//===-- amdgpuintrin.h - AMDPGU intrinsic functions
---===//
+//
+// 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
@@ -0,0 +1,154 @@
+//===-- amdgpuintrin.h - AMDPGU intrinsic functions
---===//
+//
+// 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
@@ -703,6 +715,39 @@ SDValue BPFTargetLowering::LowerSELECT_CC(SDValue Op,
SelectionDAG &DAG) const {
return DAG.getNode(BPFISD::SELECT_CC, DL, VTs, Ops);
}
+SDValue BPFTargetLowering::LowerATOMIC_LOAD(SDValue Op,
+SelectionDAG &D
https://github.com/arsenm approved this pull request.
https://github.com/llvm/llvm-project/pull/112025
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,154 @@
+//===-- amdgpuintrin.h - AMDPGU intrinsic functions
---===//
+//
+// 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
@@ -703,6 +715,39 @@ SDValue BPFTargetLowering::LowerSELECT_CC(SDValue Op,
SelectionDAG &DAG) const {
return DAG.getNode(BPFISD::SELECT_CC, DL, VTs, Ops);
}
+SDValue BPFTargetLowering::LowerATOMIC_LOAD(SDValue Op,
+SelectionDAG &D
@@ -703,6 +715,39 @@ SDValue BPFTargetLowering::LowerSELECT_CC(SDValue Op,
SelectionDAG &DAG) const {
return DAG.getNode(BPFISD::SELECT_CC, DL, VTs, Ops);
}
+SDValue BPFTargetLowering::LowerATOMIC_LOAD(SDValue Op,
+SelectionDAG &D
https://github.com/arsenm approved this pull request.
https://github.com/llvm/llvm-project/pull/112676
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
arsenm wrote:
I think const should always be used in all situations
https://github.com/llvm/llvm-project/pull/112705
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -153,12 +155,33 @@ std::string AttributeCommonInfo::getNormalizedFullName()
const {
normalizeName(getAttrName(), getScopeName(), getSyntax()));
}
+const llvm::StringMap ScopeMap = {
arsenm wrote:
Avoid static constructor? Just make this a sorted lis
https://github.com/arsenm edited
https://github.com/llvm/llvm-project/pull/114899
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1780,6 +1780,14 @@ class TargetInfo : public TransferrableTargetInfo,
return 0;
}
+ /// \returns Target specific address space for indirect (e.g. sret)
arguments.
+ /// If such an address space exists, it must be convertible to and from the
+ /// alloca address s
@@ -156,6 +157,8 @@ StringRef llvm::AMDGPU::getArchFamilyNameAMDGCN(GPUKind AK)
{
switch (AK) {
case AMDGPU::GK_GFX9_GENERIC:
return "gfx9";
+ case AMDGPU::GK_GFX9_4_GENERIC:
+return "gfx9";
arsenm wrote:
I guess it would still be gfx9 (not that
1601 - 1700 of 2827 matches
Mail list logo
