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
@@ -0,0 +1,698 @@
+//===-- 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: Apache
https://github.com/JonChesterfield dismissed
https://github.com/llvm/llvm-project/pull/81921
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/JonChesterfield commented:
Stalled on https://github.com/llvm/llvm-project/pull/81557, trying to remove
the approve mark as otherwise i'll forget about this
https://github.com/llvm/llvm-project/pull/81921
___
cfe-commits mailing lis
https://github.com/JonChesterfield approved this pull request.
https://github.com/llvm/llvm-project/pull/81921
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
JonChesterfield wrote:
OK, worked through this patch now. The noise is substantial but it's an
improvement on what we have - the overall impression is that the cmake was
originally very special cased for GPUs and now treats them very similarly to
other targets, with some careful footwork aroun
JonChesterfield wrote:
One large patch may be necessary - is it also necessary to interleave
reordering files with changing the contents? It makes the GUI diff tool we're
using here essentially useless. If the moving code between files and factoring
into functions was a separate commit we'd ha
@@ -50,31 +50,9 @@ function(collect_object_file_deps target result)
endif()
endfunction(collect_object_file_deps)
-# A rule to build a library from a collection of entrypoint objects.
-# Usage:
-# add_entrypoint_library(
-# DEPENDS
-# )
-#
-# NOTE: If one want
JonChesterfield wrote:
> IMHO I prefer to ask/request users to do the right thing.
One of the drawbacks to asking users to do the "right thing" is that it goes
something like:
- you must use global state to tell the compiler where the compiler libraries
are
- you should do this using clang con
JonChesterfield wrote:
Enable by default without cmake and fedora run their own patch is my preferred
solution.
The Siemens dev working on gcc amdgpu offloading told me they set rpath on the
executable at a conference but I haven't checked their implementation. His
attitude was that programs
JonChesterfield wrote:
> Not sure if this means isFunctionInlinable will go away in the followup
> patch, or if you plan to rewrite functions in a way that satisfies
> isFunctionInlinable. I think the end state should be that all functions go
> down the same codepath, not conditionally do some
JonChesterfield wrote:
> High level question: Does this patch eliminate the variadic call edge, or,
> does it perform inlining on very special variadic function definitions? I
> thought the former but `isFunctionInlinable`, sufficiently confused me.
This patch will rewrite calls to a variadic
JonChesterfield wrote:
> I don't really like the whole "sufficiently simple function" thing. It seems
> fragile. You should be able to just take a arbitrary internal varargs
> function, rewrite its signature to take a va_list argument, rewrite calls to
> va_start to make a copy of that va_list
@@ -0,0 +1,701 @@
+//===-- 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: Apache
1 - 100 of 198 matches
Mail list logo