Author: Jon Chesterfield
Date: 2020-07-24T20:50:46+01:00
New Revision: 679158e662aa247282b8eea4c2d60b33204171fb
URL:
https://github.com/llvm/llvm-project/commit/679158e662aa247282b8eea4c2d60b33204171fb
DIFF:
https://github.com/llvm/llvm-project/commit/679158e662aa247282b8eea4c2d60b33204171fb.di
https://github.com/JonChesterfield edited
https://github.com/llvm/llvm-project/pull/72280
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
JonChesterfield wrote:
Looks solid to me. The patch to clang is long but straightforward and the tests
look reassuringly exhaustive. Probably good that you ignored my name suggestion
of integers 0 through N.
This patch is partly motivated by us wanting device scope atomics in libc. It
removes
https://github.com/JonChesterfield approved this pull request.
This is functionally correct and useful as is - if gcc decide to do something
divergent we can change it later, it's basically an internal interface anyway.
Let's have it now and change the names if we come up with better ideas late
https://github.com/JonChesterfield approved this pull request.
Test change is suspect for a patch claiming NFC but it looks like the change is
harmless. Thanks for separating refactor from functional change
https://github.com/llvm/llvm-project/pull/72544
@@ -75,8 +75,8 @@ bb.2:
store volatile i32 0, ptr addrspace(1) undef
ret void
}
-; DEFAULTSIZE: .amdhsa_private_segment_fixed_size 4112
-; DEFAULTSIZE: ; ScratchSize: 4112
+; DEFAULTSIZE: .amdhsa_private_segment_fixed_size 16
JonChesterfield wrote:
This se
JonChesterfield wrote:
This is a wild amount of code churn from a trivial change. 10k lines of almost
all noise. Means the chances of us noticing breakage in a code review tool is
pretty low.
How about as a first patch we pass `-code-object=v4` or whatever syntax to
essentially all the tests,
JonChesterfield wrote:
The capability is more important than the naming. `__llvm_atomic_scoped_load`
would be fine, with string literals or enum or macro controlling the scope. I
also don't mind if it's a scoped argument or if we end up with
`__llvm_atomic_seqcst_device_load`, embedding all of
Author: Jon Chesterfield
Date: 2021-07-18T23:30:35+01:00
New Revision: 3e649f8ef1875f943537b5fcecdb132c9442cb7d
URL:
https://github.com/llvm/llvm-project/commit/3e649f8ef1875f943537b5fcecdb132c9442cb7d
DIFF:
https://github.com/llvm/llvm-project/commit/3e649f8ef1875f943537b5fcecdb132c9442cb7d.di
Author: Pushpinder Singh
Date: 2021-07-21T16:15:39+01:00
New Revision: 968899ad9cf17579f9867dafb35c4d97bad0863f
URL:
https://github.com/llvm/llvm-project/commit/968899ad9cf17579f9867dafb35c4d97bad0863f
DIFF:
https://github.com/llvm/llvm-project/commit/968899ad9cf17579f9867dafb35c4d97bad0863f.di
Author: Jon Chesterfield
Date: 2021-07-21T17:35:40+01:00
New Revision: d71062fbdab26fcc1c7e25ccdae410e1c61ed7f9
URL:
https://github.com/llvm/llvm-project/commit/d71062fbdab26fcc1c7e25ccdae410e1c61ed7f9
DIFF:
https://github.com/llvm/llvm-project/commit/d71062fbdab26fcc1c7e25ccdae410e1c61ed7f9.di
Author: Jon Chesterfield
Date: 2022-05-20T08:50:37+01:00
New Revision: 83c431fb9e72abbd2eddf26388245eb4963370e2
URL:
https://github.com/llvm/llvm-project/commit/83c431fb9e72abbd2eddf26388245eb4963370e2
DIFF:
https://github.com/llvm/llvm-project/commit/83c431fb9e72abbd2eddf26388245eb4963370e2.di
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
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 edited
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
@@ -0,0 +1,716 @@
+//===-- 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
@@ -0,0 +1,716 @@
+//===-- 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
@@ -0,0 +1,716 @@
+//===-- 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
@@ -0,0 +1,716 @@
+//===-- 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
@@ -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
@@ -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 edited
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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -0,0 +1,117 @@
+// RUN: %clang_cc1 -triple i386-unknown-linux-gnu -Wno-varargs -O1
-disable-llvm-passes -emit-llvm -o - %s | opt --passes=instcombine | opt
-passes="expand-variadics,default" -S | FileCheck %s
--check-prefixes=CHECK,X86Linux
JonChesterfield w
JonChesterfield wrote:
Patch run through `clang-tidy --checks=readability-identifier-naming` with the
config file in tree and recommendations applied. Some of the choices seem poor
but it's presumably acceptable.
https://github.com/llvm/llvm-project/pull/81058
_
@@ -0,0 +1,589 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
UTC_ARGS: -p --function-signature
+; RUN: opt -S --passes=expand-variadics < %s | FileCheck %s
+target datalayout =
"e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:
@@ -0,0 +1,589 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
UTC_ARGS: -p --function-signature
+; RUN: opt -S --passes=expand-variadics < %s | FileCheck %s
+target datalayout =
"e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:
@@ -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
JonChesterfield wrote:
New intrinsic sounds right - a constant frequency counter is a different thing
to a variable frequency counter.
"Steady" implies unchanging, so I'd agree with `readfixedfreqtimer` or similar.
We can't have a ratio between the two counters since one changes frequency and
JonChesterfield wrote:
The "generic IR" thing is more emergent behaviour than a documented /
intentional design.
This patch is fine - we shouldn't set macros to nonsense values - but if this
is a step towards building libc like the rocm-device-libs there may be push
back on that one.
https:/
https://github.com/JonChesterfield approved this pull request.
https://github.com/llvm/llvm-project/pull/79660
___
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.
https://github.com/llvm/llvm-project/pull/70462
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Jon Chesterfield
Date: 2020-08-19T18:11:50+01:00
New Revision: bcaa806a4747595116b538e8b75b12966e6607f6
URL:
https://github.com/llvm/llvm-project/commit/bcaa806a4747595116b538e8b75b12966e6607f6
DIFF:
https://github.com/llvm/llvm-project/commit/bcaa806a4747595116b538e8b75b12966e6607f6.di
Author: Jon Chesterfield
Date: 2020-12-15T01:11:09Z
New Revision: 4b2e7d0215021d0d1df1a6319884b21d33936265
URL:
https://github.com/llvm/llvm-project/commit/4b2e7d0215021d0d1df1a6319884b21d33936265
DIFF:
https://github.com/llvm/llvm-project/commit/4b2e7d0215021d0d1df1a6319884b21d33936265.diff
L
Author: Jon Chesterfield
Date: 2020-12-16T17:00:19Z
New Revision: c0619d3b21cd420b9faf15f14db0816787c44ded
URL:
https://github.com/llvm/llvm-project/commit/c0619d3b21cd420b9faf15f14db0816787c44ded
DIFF:
https://github.com/llvm/llvm-project/commit/c0619d3b21cd420b9faf15f14db0816787c44ded.diff
L
Author: Jon Chesterfield
Date: 2020-12-17T16:09:33Z
New Revision: daf39e3f2dba18bd39cd89a1c91bae126a31d4fe
URL:
https://github.com/llvm/llvm-project/commit/daf39e3f2dba18bd39cd89a1c91bae126a31d4fe
DIFF:
https://github.com/llvm/llvm-project/commit/daf39e3f2dba18bd39cd89a1c91bae126a31d4fe.diff
L
Author: JonChesterfield
Date: 2020-10-28T14:25:36Z
New Revision: 5d02ca49a294848b533adf7dc1d1275d125ef587
URL:
https://github.com/llvm/llvm-project/commit/5d02ca49a294848b533adf7dc1d1275d125ef587
DIFF:
https://github.com/llvm/llvm-project/commit/5d02ca49a294848b533adf7dc1d1275d125ef587.diff
LO
Author: Jon Chesterfield
Date: 2020-10-29T16:25:13Z
New Revision: dee7704829bd421ad3cce4b2132d28f4459b7319
URL:
https://github.com/llvm/llvm-project/commit/dee7704829bd421ad3cce4b2132d28f4459b7319
DIFF:
https://github.com/llvm/llvm-project/commit/dee7704829bd421ad3cce4b2132d28f4459b7319.diff
L
Author: Ethan Stewart
Date: 2021-06-23T15:26:09+01:00
New Revision: 5dfdc1812d9b9c043204d39318f6446424d8f2d7
URL:
https://github.com/llvm/llvm-project/commit/5dfdc1812d9b9c043204d39318f6446424d8f2d7
DIFF:
https://github.com/llvm/llvm-project/commit/5dfdc1812d9b9c043204d39318f6446424d8f2d7.diff
Author: Jon Chesterfield
Date: 2021-07-30T22:07:00+01:00
New Revision: 7f97ddaf8aa0062393e866b63e68c9f74da375fb
URL:
https://github.com/llvm/llvm-project/commit/7f97ddaf8aa0062393e866b63e68c9f74da375fb
DIFF:
https://github.com/llvm/llvm-project/commit/7f97ddaf8aa0062393e866b63e68c9f74da375fb.di
Author: Jon Chesterfield
Date: 2021-08-05T18:46:57+01:00
New Revision: 509854b69cea0c9261ac21ceb22012a53e7a800b
URL:
https://github.com/llvm/llvm-project/commit/509854b69cea0c9261ac21ceb22012a53e7a800b
DIFF:
https://github.com/llvm/llvm-project/commit/509854b69cea0c9261ac21ceb22012a53e7a800b.di
Author: Jon Chesterfield
Date: 2021-08-12T17:30:22+01:00
New Revision: b6113548c9217fb8a6d0e9ac5bef5584c1aa614d
URL:
https://github.com/llvm/llvm-project/commit/b6113548c9217fb8a6d0e9ac5bef5584c1aa614d
DIFF:
https://github.com/llvm/llvm-project/commit/b6113548c9217fb8a6d0e9ac5bef5584c1aa614d.di
Author: Jon Chesterfield
Date: 2021-08-12T17:44:36+01:00
New Revision: 6a8e5120abacdfe0f05c9670782e59e2b729a318
URL:
https://github.com/llvm/llvm-project/commit/6a8e5120abacdfe0f05c9670782e59e2b729a318
DIFF:
https://github.com/llvm/llvm-project/commit/6a8e5120abacdfe0f05c9670782e59e2b729a318.di
Author: Jon Chesterfield
Date: 2021-08-18T20:47:33+01:00
New Revision: 21d91a8ef319eec9c2c272e19beee726429524aa
URL:
https://github.com/llvm/llvm-project/commit/21d91a8ef319eec9c2c272e19beee726429524aa
DIFF:
https://github.com/llvm/llvm-project/commit/21d91a8ef319eec9c2c272e19beee726429524aa.di
Author: Jon Chesterfield
Date: 2021-08-19T02:22:11+01:00
New Revision: dbd7bad9ad9bc32538e324417c23387bf4ac7747
URL:
https://github.com/llvm/llvm-project/commit/dbd7bad9ad9bc32538e324417c23387bf4ac7747
DIFF:
https://github.com/llvm/llvm-project/commit/dbd7bad9ad9bc32538e324417c23387bf4ac7747.di
Author: Jon Chesterfield
Date: 2021-08-19T13:25:42+01:00
New Revision: 77579b99e9ce1638ca696fa7c3872ae8668d997d
URL:
https://github.com/llvm/llvm-project/commit/77579b99e9ce1638ca696fa7c3872ae8668d997d
DIFF:
https://github.com/llvm/llvm-project/commit/77579b99e9ce1638ca696fa7c3872ae8668d997d.di
Author: Jon Chesterfield
Date: 2021-10-28T00:41:45+01:00
New Revision: 33427fdb7b52b79ce5e25b7e14e0f1a44d876bd2
URL:
https://github.com/llvm/llvm-project/commit/33427fdb7b52b79ce5e25b7e14e0f1a44d876bd2
DIFF:
https://github.com/llvm/llvm-project/commit/33427fdb7b52b79ce5e25b7e14e0f1a44d876bd2.di
Author: Jon Chesterfield
Date: 2021-10-28T01:01:53+01:00
New Revision: 6c7b203d1d7000269215ab5b3d329ab03dc85e42
URL:
https://github.com/llvm/llvm-project/commit/6c7b203d1d7000269215ab5b3d329ab03dc85e42
DIFF:
https://github.com/llvm/llvm-project/commit/6c7b203d1d7000269215ab5b3d329ab03dc85e42.di
Author: Jon Chesterfield
Date: 2021-10-28T12:34:01+01:00
New Revision: 4d50803ce49ce6b57c4865361c9ba0ad7063b7be
URL:
https://github.com/llvm/llvm-project/commit/4d50803ce49ce6b57c4865361c9ba0ad7063b7be
DIFF:
https://github.com/llvm/llvm-project/commit/4d50803ce49ce6b57c4865361c9ba0ad7063b7be.di
Author: Jon Chesterfield
Date: 2021-11-08T15:00:08Z
New Revision: 2c37ae6d14cf263724720f56fc34b4579a6e5c1c
URL:
https://github.com/llvm/llvm-project/commit/2c37ae6d14cf263724720f56fc34b4579a6e5c1c
DIFF:
https://github.com/llvm/llvm-project/commit/2c37ae6d14cf263724720f56fc34b4579a6e5c1c.diff
L
Author: Jon Chesterfield
Date: 2021-11-08T18:38:00Z
New Revision: db81d8f6c4d6c4f8dfaa036d6959528c9f14e7d7
URL:
https://github.com/llvm/llvm-project/commit/db81d8f6c4d6c4f8dfaa036d6959528c9f14e7d7
DIFF:
https://github.com/llvm/llvm-project/commit/db81d8f6c4d6c4f8dfaa036d6959528c9f14e7d7.diff
L
Author: Jon Chesterfield
Date: 2021-11-08T20:28:57Z
New Revision: 0fa45d6d8067d71a8dccac7d942c53b5fd80e499
URL:
https://github.com/llvm/llvm-project/commit/0fa45d6d8067d71a8dccac7d942c53b5fd80e499
DIFF:
https://github.com/llvm/llvm-project/commit/0fa45d6d8067d71a8dccac7d942c53b5fd80e499.diff
L
Author: Jon Chesterfield
Date: 2021-11-10T15:30:56Z
New Revision: 27177b82d4ca4451f288168fc1e06c0736afbdaf
URL:
https://github.com/llvm/llvm-project/commit/27177b82d4ca4451f288168fc1e06c0736afbdaf
DIFF:
https://github.com/llvm/llvm-project/commit/27177b82d4ca4451f288168fc1e06c0736afbdaf.diff
L
Author: Jon Chesterfield
Date: 2021-11-15T15:56:01Z
New Revision: 0e738323a9c445e31b4e1b1dcb2beb19d6f103ef
URL:
https://github.com/llvm/llvm-project/commit/0e738323a9c445e31b4e1b1dcb2beb19d6f103ef
DIFF:
https://github.com/llvm/llvm-project/commit/0e738323a9c445e31b4e1b1dcb2beb19d6f103ef.diff
L
Author: Jon Chesterfield
Date: 2023-01-25T21:40:35Z
New Revision: bfe4514add5b7ab7e1f06248983a7162d734cffb
URL:
https://github.com/llvm/llvm-project/commit/bfe4514add5b7ab7e1f06248983a7162d734cffb
DIFF:
https://github.com/llvm/llvm-project/commit/bfe4514add5b7ab7e1f06248983a7162d734cffb.diff
L
https://github.com/JonChesterfield approved this pull request.
LinkerWrapper turning into a linker is kind of inevitable and not a very happy
thing.
One option would be to lean on lld for amdgpu and split out the nvptx stuff in
the hopes that we eventually have an alternative to nvlink, but it
https://github.com/JonChesterfield commented:
This stuff looks very cuda/opencl specific. It's definitely surprising for C++
code. Do we need it for openmp? If not it seems better to guard the hack with
visibility behind if (hip)
https://github.com/llvm/llvm-project/pull/68264
@@ -308,12 +308,13 @@ static bool requiresAMDGPUProtectedVisibility(const Decl
*D,
if (GV->getVisibility() != llvm::GlobalValue::HiddenVisibility)
return false;
- return D->hasAttr() ||
- (isa(D) && D->hasAttr()) ||
- (isa(D) &&
- (D->hasAttr()
Author: Jon Chesterfield
Date: 2020-03-17T21:22:23Z
New Revision: c45eaeabb77a926f4f1cf3c1e9311e9d66e0ee2a
URL:
https://github.com/llvm/llvm-project/commit/c45eaeabb77a926f4f1cf3c1e9311e9d66e0ee2a
DIFF:
https://github.com/llvm/llvm-project/commit/c45eaeabb77a926f4f1cf3c1e9311e9d66e0ee2a.diff
L
Author: Jon Chesterfield
Date: 2020-03-17T22:15:19Z
New Revision: 1d19b153955a87bd0f83c8a6a072d69239f76d63
URL:
https://github.com/llvm/llvm-project/commit/1d19b153955a87bd0f83c8a6a072d69239f76d63
DIFF:
https://github.com/llvm/llvm-project/commit/1d19b153955a87bd0f83c8a6a072d69239f76d63.diff
L
Author: Jon Chesterfield
Date: 2020-03-17T23:33:12Z
New Revision: cc691f3384c593849d3a5ab468d8e5ac6f707dab
URL:
https://github.com/llvm/llvm-project/commit/cc691f3384c593849d3a5ab468d8e5ac6f707dab
DIFF:
https://github.com/llvm/llvm-project/commit/cc691f3384c593849d3a5ab468d8e5ac6f707dab.diff
L
Hi,
I believe this is being sent to the correct list. Please let me know if
there is a better choice.
The clang-format option SpaceBeforeParens "Always" does not insert a space
before the opening parenthesis of an overloaded operator function. The
attached patch against trunk resolves this.
Kind
JonChesterfield created this revision.
JonChesterfield added a subscriber: cfe-commits.
JonChesterfield set the repository for this revision to rL LLVM.
Herald added a subscriber: klimek.
The clang-format option SpaceBeforeParens "Always" does not insert a space
before the opening parenthesis of
JonChesterfield added a comment.
Thanks. I have no commit access.
Repository:
rL LLVM
http://reviews.llvm.org/D11957
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -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
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
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:
> 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:
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:
> 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
@@ -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:
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
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
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
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 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
@@ -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
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
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:
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
@@ -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
@@ -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 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
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
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
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
_
@@ -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")
@@ -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
@@ -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
@@ -116,8 +116,7 @@ class LLVM_LIBRARY_VISIBILITY NVPTXTargetInfo : public
TargetInfo {
}
BuiltinVaListKind getBuiltinVaListKind() const override {
-// FIXME: implement
-return TargetInfo::CharPtrBuiltinVaList;
+return TargetInfo::VoidPtrBuiltinVaList;
---
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
1 - 100 of 293 matches
Mail list logo
