JonChesterfield wrote:
Stringing the pieces together, we may have been conflating opencl-the-language
with opencl-the-implementation.
Let's go with the first line of attack, no language special casing here, no
checking seq-cst and appending one-as.
Opencl the implementation won't care because
JonChesterfield wrote:
> This one-as business seems like it's cruft from before MMRAs. Can we rip them
> out and replace them with MMRAs for OpenCL?
https://llvm.org/docs/MemoryModelRelaxationAnnotations.html calls out the
opencl fence as a motivating example which suggests either yes, or we s
https://github.com/JonChesterfield requested changes to this pull request.
"You need to leave a comment indicating the requested changes."
https://github.com/llvm/llvm-project/pull/120095
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://
JonChesterfield wrote:
@b-sumner has useful context on this. I won't paraphrase, but it sounds like
the block deleted here has the right semantics for opencl, where "seqcst" has
some special meaning and generally the semantics don't totally make sense to
me. Suggest we amend this to "if opencl
https://github.com/JonChesterfield edited
https://github.com/llvm/llvm-project/pull/120095
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/JonChesterfield approved this pull request.
Explicitly marking green, even if this commit upsets something else in the
backend having the concurrency primitives default to racy is clearly bad.
https://github.com/llvm/llvm-project/pull/120095
__
JonChesterfield wrote:
I would say this change is obviously correct, but I can't see why it was
introduced and vaguely fear tripping over abhorrent behaviour in the backend.
Can you send this down the internal CI pipeline to pick up some more runtime
testing (unless amd-stg-open is already def
JonChesterfield wrote:
> Would only work for Linux unfortunately, unless some Windows driver developer
> out there knows if there's some similar win32 magic.
Windows getting subprocess calls until their driver catches up (or someone
points out how to do this) seems fine to me. Linux people get
JonChesterfield wrote:
Oh. I now see there was a bunch of discussion about this, will add some context.
The driver has a hard limit on how many processes can open it at a time. clang
calls this utility to ask what gpu to compile for by default. If you put those
together, a parallel build on a
https://github.com/JonChesterfield approved this pull request.
Absolutely yes, awesome. I had a todo to have the kernel export this under
sysfs literally years ago and didn't get around to working out their commit
structure, delighted to see it is exposed. The unreliable hsa calls has been a
c
JonChesterfield wrote:
Awesome! This is absolutely something that has been on my todo stack for ages
and it's very good to see someone else writing the thing.
It looks like the implementation is contentious so I'll leave that for the
moment. Under some time constraints so please forgive the le
https://github.com/JonChesterfield approved this pull request.
Error looks good. Might want to add a case for "dynamic __shared__" to the test
file as the syntax is very close to the case being diagnosed - iirc it's things
like
```cuda
extern __shared__ float array[];
```
Some existing handli
JonChesterfield wrote:
Probably want a longer prefix. _gpu or_llvm or similar.
If the shared header gets the declarations then people can include the intrin.h
and look at it to see what functions they have available, without going and
looking through all the implementations. That seems like a
JonChesterfield wrote:
Sanizer passes setting a "no sanitizer" magic variable is backwards.
If this behaviour is the way to go, have clang set a "needs_asan_lowering" or
whatever and have the corresponding pass remove it.
It shouldn't be necessary to emit ever increasing lists of pass and targ
@@ -116,8 +116,7 @@ class LLVM_LIBRARY_VISIBILITY NVPTXTargetInfo : public
TargetInfo {
}
BuiltinVaListKind getBuiltinVaListKind() const override {
-// FIXME: implement
-return TargetInfo::CharPtrBuiltinVaList;
+return TargetInfo::VoidPtrBuiltinVaList;
---
@@ -54,7 +54,34 @@ class MockArgList {
}
template LIBC_INLINE T next_var() {
-++arg_counter;
+arg_counter++;
+return T(arg_counter);
+ }
+
+ size_t read_count() const { return arg_counter; }
+};
+
+// Used by the GPU implementation to parse how many bytes ne
@@ -942,6 +942,36 @@ struct Amdgpu final : public VariadicABIInfo {
}
};
+struct NVPTX final : public VariadicABIInfo {
+
+ bool enableForTarget() override { return true; }
+
+ bool vaListPassedInSSARegister() override { return true; }
+
+ Type *vaListType(LLVMContext &Ct
https://github.com/JonChesterfield edited
https://github.com/llvm/llvm-project/pull/96369
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -942,6 +942,36 @@ struct Amdgpu final : public VariadicABIInfo {
}
};
+struct NVPTX final : public VariadicABIInfo {
+
+ bool enableForTarget() override { return true; }
+
+ bool vaListPassedInSSARegister() override { return true; }
+
+ Type *vaListType(LLVMContext &Ct
@@ -215,7 +219,10 @@ void NVPTXABIInfo::computeInfo(CGFunctionInfo &FI) const {
RValue NVPTXABIInfo::EmitVAArg(CodeGenFunction &CGF, Address VAListAddr,
QualType Ty, AggValueSlot Slot) const {
- llvm_unreachable("NVPTX does not support varargs")
JonChesterfield wrote:
I've passed some types to nvcc on godbolt and tried to decode the results. It
looks like it's passing everything with natural alignment, flattened, with
total disregard to the minimum slot size premise clang uses.
https://github.com/llvm/llvm-project/pull/96369
_
JonChesterfield wrote:
Ah yes, libc code doing the equivalent of va_arg assuming natural alignment
when the underlying buffer is a packed struct with fields padded to four bytes
would not work. That would be "fixed" by changing the compiler to match the
assumption made by libc, but it seems mu
https://github.com/JonChesterfield requested changes to this pull request.
Patch should not land. Need to know what bug this was trying to address to
guess at what the right fix would be.
https://github.com/llvm/llvm-project/pull/96370
___
cfe-commits
https://github.com/JonChesterfield requested changes to this pull request.
The amdgpu patch is incorrect, see
https://github.com/llvm/llvm-project/pull/96370/
The nvptx lowering looks dubious - values smaller than slot size should be
passed with the same alignment as the slot and presently are
@@ -942,6 +942,36 @@ struct Amdgpu final : public VariadicABIInfo {
}
};
+struct NVPTX final : public VariadicABIInfo {
+
+ bool enableForTarget() override { return true; }
+
+ bool vaListPassedInSSARegister() override { return true; }
+
+ Type *vaListType(LLVMContext &Ct
@@ -0,0 +1,77 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --version 5
+// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -emit-llvm -o - %s | FileCheck
%s
+
+extern void varargs_simple(int, ...);
+
+// CHECK-LABEL: define dso_local vo
JonChesterfield wrote:
This PR is invalid.
First, the alignment on the eight byte pointer is supposed to be four.
Increasing it to 8 makes things worse.
Second, I can't see any support for the claim that the code is incrementing by
the alignment of the value, as opposed to the size.
The fram
@@ -938,6 +938,37 @@ struct Amdgpu final : public VariadicABIInfo {
}
};
+struct NVPTX final : public VariadicABIInfo {
+
+ bool enableForTarget() override { return true; }
+
+ bool vaListPassedInSSARegister() override { return true; }
+
+ Type *vaListType(LLVMContext &Ct
https://github.com/JonChesterfield edited
https://github.com/llvm/llvm-project/pull/96015
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/JonChesterfield commented:
With the possible exception of some alignment handling this looks about as I'd
expect it to. Ideally we'd get some feedback from nvptx-associated people but
fixing libc is a good sign
https://github.com/llvm/llvm-project/pull/96015
___
@@ -17,6 +17,8 @@
#define MODULE_PASS(NAME, CREATE_PASS)
#endif
MODULE_PASS("generic-to-nvvm", GenericToNVVMPass())
+MODULE_PASS("expand-variadics",
JonChesterfield wrote:
This shouldn't be necessary, I think. I don't recall whether I removed it from
the amdg
@@ -203,8 +203,15 @@ ABIArgInfo NVPTXABIInfo::classifyArgumentType(QualType Ty)
const {
void NVPTXABIInfo::computeInfo(CGFunctionInfo &FI) const {
if (!getCXXABI().classifyReturnType(FI))
FI.getReturnInfo() = classifyReturnType(FI.getReturnType());
- for (auto &I : FI.a
JonChesterfield wrote:
Majority is landed as https://github.com/llvm/llvm-project/pull/93362
https://github.com/llvm/llvm-project/pull/81058
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-com
https://github.com/JonChesterfield closed
https://github.com/llvm/llvm-project/pull/81058
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/JonChesterfield closed
https://github.com/llvm/llvm-project/pull/89007
___
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));
JonChesterfield wrot
JonChesterfield wrote:
If there's no va_start and we're optimising there's no work to do. Otherwise
when lowering we still transform declarations (which have no basic blocks) and
calls to unknown pointers, so that separate compilation works. That's why
knowing it's the whole program would be u
@@ -8,10 +8,15 @@ add_custom_target(libc-long-running-tests)
add_subdirectory(UnitTest)
-if(LIBC_TARGET_OS_IS_GPU AND
JonChesterfield wrote:
This is helpful for me working out why libc isn't running tests but otherwise
unrelated to this PR, I'll drop it fro
JonChesterfield wrote:
Early exit on lack of va_start will be incorrect in the lowering case, which is
the only one enabled by default. I believe existing comments are all addressed.
Precommit the cmake diagnostic tweak sounds good, would you like to land that?
https://github.com/llvm/llvm-pro
JonChesterfield wrote:
We can check for the va_start which is a good approximation, but there can be a
variadic function pointer from another module and the only place that would
show up is a call instruction, and the only way to find that is enumeration.
Amdgpu can somewhat cheat using the wh
JonChesterfield wrote:
An offline suggestion from Pierre is that this should early-exit if there are
no variadic functions in the module. That's a good thing, I'd like to consider
it another of the increase-complexity-for-decreased-compile-time to implement
after something has landed.
https:/
JonChesterfield wrote:
Thanks @Pierre-vh, I think those are all applied. Also removed llvm:: from some
other places, and remembered that llvm doesn't like the if () {braces} which
are so useful for git merge not introducing bugs so removed the majority of
those as well. Feel confident enough a
https://github.com/JonChesterfield 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
@@ -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/JonChesterfield 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
@@ -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
JonChesterfield wrote:
Majority of review comments applied. Merged 94083 (with apologies to Matt) and
rebased.
I claim the top level strategy of "turn ... into va_list then fix up known call
sites" is a reasonable strategy for optimising variadic functions. The target
specific quirks being ab
https://github.com/JonChesterfield 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
@@ -33,6 +33,7 @@ static_library("IPO") {
"DeadArgumentElimination.cpp",
"ElimAvailExtern.cpp",
"EmbedBitcodePass.cpp",
+"ExpandVariadics.cpp",
JonChesterfield wrote:
Nice, I did not know what. I am indeed not a BUILD.gn user.
https://github.c
JonChesterfield wrote:
Slightly jumped the gun on this patch because Eli just wrote a bunch of useful
things on #93362 and there's therefore a credible chance that rebasing on this
will get the pass in the hands of other people soon, giving libc sprintf and so
forth.
https://github.com/llvm/l
https://github.com/JonChesterfield closed
https://github.com/llvm/llvm-project/pull/94083
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -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
JonChesterfield wrote:
@arsenm You're right about passing larger things indirectly. I'm intending to
land this as-is, with the types inlined, as that unblocks #93362. I'm nervous
that the extra pointer indirection will hit the same memory error that tweaking
codegen in that patch hits (it's a
JonChesterfield wrote:
I wish to ship this as-is. This patch is carefully constructed to be zero risk
and landing it significantly improves the chances of zero-overhead varargs
shipping. This revision passes the amdgpu libc tests. The tests are fragile to
seemingly trivial changes to the IR ge
JonChesterfield wrote:
I've got a workaround for the amdgpu memory error and this hasn't attracted any
comments so closing it.
https://github.com/llvm/llvm-project/pull/93974
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.o
https://github.com/JonChesterfield closed
https://github.com/llvm/llvm-project/pull/93974
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
JonChesterfield wrote:
Finally managed to reproduce the libc failure. Thanks to Joseph for helping
debug through the cmake. This patch as written was too optimistic about
addrspacecast, a significantly more paranoid version behaves correctly (i.e.
all the libc tests pass, this patch can be ame
JonChesterfield wrote:
That's our call really. Right now this passes everything as whatever type it
claimed to be as far as creating the call instruction goes, then variadic
lowering pastes them all into a single structure with four byte alignment on
every field.
Tagging some parameters as by
@@ -103,19 +104,27 @@ void AMDGPUABIInfo::computeInfo(CGFunctionInfo &FI) const
{
if (!getCXXABI().classifyReturnType(FI))
FI.getReturnInfo() = classifyReturnType(FI.getReturnType());
+ unsigned ArgumentIndex = 0;
+ const unsigned numFixedArguments = FI.getNumRequired
https://github.com/JonChesterfield edited
https://github.com/llvm/llvm-project/pull/94083
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -10,6 +10,50 @@
#include "test/UnitTest/Test.h"
+#include "src/__support/OSUtil/io.h"
+#include "src/__support/integer_to_string.h"
+using namespace LIBC_NAMESPACE;
+
+namespace {
+
+void nl() { write_to_stderr("\n"); }
+void dump(const char *s) {
+ write_to_stderr(s);
+
@@ -10,6 +10,50 @@
#include "test/UnitTest/Test.h"
+#include "src/__support/OSUtil/io.h"
+#include "src/__support/integer_to_string.h"
+using namespace LIBC_NAMESPACE;
+
+namespace {
+
+void nl() { write_to_stderr("\n"); }
+void dump(const char *s) {
+ write_to_stderr(s);
+
JonChesterfield wrote:
I've spawned #93974 in case we can land the target independent part in parallel
with me trying to debug the amdgpu/libc error. Maintaining different branches
with different variations on what subset is implemented is confusing me quite a
lot and leads to reviewers seeing
JonChesterfield wrote:
This is #93362 with the amdgpu part removed as debugging the reported amdgpu
libc memory error is taking longer than one hoped and I'd like to unblock
implementing other targets.
As it stands this is dead code other than the wasm tests which has the
advantage that it de
https://github.com/JonChesterfield edited
https://github.com/llvm/llvm-project/pull/93974
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -103,19 +104,27 @@ void AMDGPUABIInfo::computeInfo(CGFunctionInfo &FI) const
{
if (!getCXXABI().classifyReturnType(FI))
FI.getReturnInfo() = classifyReturnType(FI.getReturnType());
+ unsigned ArgumentIndex = 0;
+ const unsigned numFixedArguments = FI.getNumRequired
JonChesterfield wrote:
Joseph reports "memory error" from a libc test when running with this patch.
This is unfortunate. I haven't reproduced that yet (I don't mean libc passes, I
mean libc fails with or without this patch). The blast radius for "memory
error" on amdgpu is wide but there is ve
@@ -115,7 +115,13 @@ void AMDGPUABIInfo::computeInfo(CGFunctionInfo &FI) const {
Address AMDGPUABIInfo::EmitVAArg(CodeGenFunction &CGF, Address VAListAddr,
QualType Ty) const {
- llvm_unreachable("AMDGPU does not support varargs");
+ const bo
@@ -197,12 +206,20 @@ ABIArgInfo
AMDGPUABIInfo::classifyKernelArgumentType(QualType Ty) const {
return ABIArgInfo::getDirect(LTy, 0, nullptr, false);
}
-ABIArgInfo AMDGPUABIInfo::classifyArgumentType(QualType Ty,
+ABIArgInfo AMDGPUABIInfo::classifyArgumentType(QualType Ty,
JonChesterfield wrote:
I think the comments here are fed into
https://github.com/llvm/llvm-project/pull/93362 successfully, will go through
the list again to check.
https://github.com/llvm/llvm-project/pull/89007
___
cfe-commits mailing list
cfe-comm
JonChesterfield wrote:
Dropping this in favour of
[93362](https://github.com/llvm/llvm-project/pull/93362) on risk assessment
grounds.
This commit enabled ad hoc testing from wasm, x64, and aarch64. However if it's
buggy, it'll show up on those targets, which should make the code owners
relu
https://github.com/JonChesterfield closed
https://github.com/llvm/llvm-project/pull/92850
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
JonChesterfield wrote:
[inline-then-fold-variadics.cpp](https://github.com/llvm/llvm-project/pull/92850/commits/15061bfbc2dc06de5bac32628389386cadaa5632#diff-0a9893e04ae7e0a5692ad93dfb73d6efa992953f7e9eebb68c1a3f4acd457e1e)
is the motivating example for optimisation - simple variadic functions a
@@ -1,5 +1,6 @@
// REQUIRES: aarch64-registered-target
-// RUN: %clang_cc1 -triple aarch64 -target-feature +neon -emit-llvm -O2 -o -
%s | FileCheck %s
+// RUN: %clang_cc1 -triple aarch64 -target-feature +neon -emit-llvm -O2 -o -
%s -mllvm -expand-variadics-override=disable | Fi
https://github.com/JonChesterfield closed
https://github.com/llvm/llvm-project/pull/92836
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
JonChesterfield wrote:
Dropped the NFC tag from the commit message. The machine code is expected to be
the same or negligibly better, this patch makes some tests more legible for a
different patch. Thanks for the quick review!
https://github.com/llvm/llvm-project/pull/92836
___
https://github.com/JonChesterfield edited
https://github.com/llvm/llvm-project/pull/92836
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/JonChesterfield created
https://github.com/llvm/llvm-project/pull/92836
None
>From b08088ddb37d2a03d321e3256ae19328dd7c502e Mon Sep 17 00:00:00 2001
From: Jon Chesterfield
Date: Mon, 20 May 2024 23:07:50 +0100
Subject: [PATCH] [AArch64][NFC] Use ptrmask for vaarg stack align
JonChesterfield wrote:
Aarch64 has a dedicated floating point region in the va_list structure. Is the
intent of this patch to globally disable the use of that, such that clang
should arrange to put floating point values in the stack fallback area instead?
https://github.com/llvm/llvm-project/p
@@ -0,0 +1,1056 @@
+//===-- 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,1056 @@
+//===-- 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
JonChesterfield wrote:
Drive by fixes to some of Matt's comments. Caught a missing line in a .def file
for NVPTX through luck due to the enum rename which means the
Other/new-pm-thinlto-postlink-samplepgo-defaults.ll style tests need to be
patched again - leaving that for now as I want to chec
@@ -0,0 +1,1056 @@
+//===-- 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,1056 @@
+//===-- 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
@@ -115,7 +115,13 @@ void AMDGPUABIInfo::computeInfo(CGFunctionInfo &FI) const {
Address AMDGPUABIInfo::EmitVAArg(CodeGenFunction &CGF, Address VAListAddr,
QualType Ty) const {
- llvm_unreachable("AMDGPU does not support varargs");
+ const bo
@@ -0,0 +1,1056 @@
+//===-- 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
@@ -115,7 +115,13 @@ void AMDGPUABIInfo::computeInfo(CGFunctionInfo &FI) const {
Address AMDGPUABIInfo::EmitVAArg(CodeGenFunction &CGF, Address VAListAddr,
QualType Ty) const {
- llvm_unreachable("AMDGPU does not support varargs");
+ const bo
@@ -0,0 +1,1056 @@
+//===-- 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,1056 @@
+//===-- 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
@@ -154,11 +154,20 @@ llvm::Value
*CodeGen::emitRoundPointerUpToAlignment(CodeGenFunction &CGF,
llvm::Value *Ptr,
CharUnits Align) {
// OverflowArgArea = (OverflowArgArea
Author: Jon Chesterfield
Date: 2024-04-02T23:21:48+01:00
New Revision: b4adb42151bbfa80be4cf6d076cbe5edf680693e
URL:
https://github.com/llvm/llvm-project/commit/b4adb42151bbfa80be4cf6d076cbe5edf680693e
DIFF:
https://github.com/llvm/llvm-project/commit/b4adb42151bbfa80be4cf6d076cbe5edf680693e.di
JonChesterfield wrote:
I'm sorry to hear that. I've only used the ENABLE_RUNTIMES in the context of
compiling clang first, and then compiling the libraries under runtime with that
clang. The recursive invocation drops (most) arguments passed to cmake which
has been obstructive in the past.
Wi
https://github.com/JonChesterfield created
https://github.com/llvm/llvm-project/pull/86351
When a CMakeLists.txt is missing a 'project' statement you get the default
supported languages of C and CXX.
https://cmake.org/cmake/help/latest/command/project.html. The help says ASM
should be listed
https://github.com/JonChesterfield approved this pull request.
I like this a lot, thank you.
https://github.com/llvm/llvm-project/pull/80460
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-com
JonChesterfield wrote:
Ah OK, so split every variadic definition and let the inliner sort it out
afterwards. Yes, I'm good with that. Tests either get messier or add a call to
the inliner. Will update the PR correspondingly, solid simplification, thanks!
Discard the combinatorial testing comme
1 - 100 of 211 matches
Mail list logo
