https://github.com/zhaoqi5 updated
https://github.com/llvm/llvm-project/pull/122999
>From e37c2933125a65e627949557fba7a606d41db716 Mon Sep 17 00:00:00 2001
From: Qi Zhao
Date: Tue, 14 Jan 2025 21:35:31 +0800
Subject: [PATCH] [LoongArch] Merge base and offset for tls-le code sequence
Adapt the
https://github.com/zhaoqi5 updated
https://github.com/llvm/llvm-project/pull/122999
>From ac63a4f1c8e8d1b3831c83c5fab2a139a284dcc6 Mon Sep 17 00:00:00 2001
From: Qi Zhao
Date: Tue, 14 Jan 2025 21:35:31 +0800
Subject: [PATCH] [LoongArch] Merge base and offset for tls-le code sequence
Adapt the
https://github.com/ilovepi updated
https://github.com/llvm/llvm-project/pull/121820
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/ilovepi updated
https://github.com/llvm/llvm-project/pull/121820
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
shiltian wrote:
> how about assuming the strict triple format first, this will make the generic
> GPU arch work with strict triple.
That doesn't work if someone write a 3-tuple with a generic target because
neither pass can handle that.
https://github.com/llvm/llvm-project/pull/122629
___
@@ -1949,6 +1949,13 @@ bool SITargetLowering::isExtractSubvectorCheap(EVT
ResVT, EVT SrcVT,
return Index == 0;
}
+bool SITargetLowering::isExtractVecEltCheap(EVT VT, unsigned Index) const {
+ // TODO: This should be more aggressive, particular for 16-bit element
+ // vect
https://github.com/shiltian updated
https://github.com/llvm/llvm-project/pull/122629
>From e7eac39e7fd0516069edbc1b0b62bf8eced359df Mon Sep 17 00:00:00 2001
From: Shilei Tian
Date: Sun, 12 Jan 2025 18:01:55 -0500
Subject: [PATCH] [OffloadBundler] Rework the ctor of `OffloadTargetInfo` to
suppo
yxsamliu wrote:
how about assuming the strict triple format first, this will make the generic
GPU arch work with strict triple.
If the first assumption fails, then fall back to the legacy parsing, that is,
assuming no '-' in GPU arch and split at the right most '-'. This way, the old
target I
yxsamliu wrote:
> > > Still, I think it is possible to make it generic with minor assumption.
> > > Let's say you are now about to parsing the final part of the target ID
> > > string which may be either "env-cpu" or "cpu" without env.
> >
> >
> > This is not actually the issue. The issue is
yxsamliu wrote:
> > Still, I think it is possible to make it generic with minor assumption.
> > Let's say you are now about to parsing the final part of the target ID
> > string which may be either "env-cpu" or "cpu" without env.
>
> This is not actually the issue. The issue is when the cpu is
agozillon wrote:
Performed an update of PR 3 to address some reviewer nits, and then a rebase,
the rebase has unfortunately brought in some code that will break the CI /
patch series for the moment. However, I need to create a seperate PR to address
it as it's a little unrelated to the changes
https://github.com/agozillon updated
https://github.com/llvm/llvm-project/pull/119589
>From 82f879526d8618b40a6bc83d27c9acc16422de6e Mon Sep 17 00:00:00 2001
From: agozillon
Date: Wed, 11 Dec 2024 04:52:00 -0600
Subject: [PATCH] [Flang][OpenMP][MLIR] Initial declare target to for variables
imp
https://github.com/agozillon updated
https://github.com/llvm/llvm-project/pull/119588
>From ed1fb2d5340505faa3b14253eb4395b33a69f63e Mon Sep 17 00:00:00 2001
From: agozillon
Date: Wed, 11 Dec 2024 09:11:58 -0600
Subject: [PATCH] [MLIR][OpenMP] Introduce overlapped record type map support
This
shiltian wrote:
> Still, I think it is possible to make it generic with minor assumption. Let's
> say you are now about to parsing the final part of the target ID string which
> may be either "env-cpu" or "cpu" without env.
This is not actually the issue. The issue is when the cpu is a generic
yxsamliu wrote:
> First of all, I don't think it can fix the issue in a robust way. Second,
> `generic` is already a valid target/cpu/offload target.
>
> Unless we do something like, if the last part is `generic`, we keep looking
> forward until we can construct a valid target. That has no dif
shiltian wrote:
First of all, I don't think it can fix the issue in a robust way. Second,
`generic` is already a valid target/cpu/offload target.
Unless we do something like, if the last part is `generic`, we keep looking
forward until we can construct a valid target. That has no difference th
yxsamliu wrote:
> Somewhere for the linker wrapper I just checked if the triple was recognized,
> you could probably just take strings after the `-` until it stops working.
+1
It would be bad user experience to break existing app. It would be low risk to
have env+cpu to be a valid cpu. So you
preames wrote:
> > Isn't the condition in code in terms of VecIn.size() == 2? I believe that
> > VecIn is the _unique_ input elements, right? Which is distinct from the
> > number of elements in the destination type? (Am I just misreading? I only
> > skimmed this.)
>
> VecIn is collecting onl
https://github.com/shiltian updated
https://github.com/llvm/llvm-project/pull/122629
>From c2588fee406f43e6cc1fc1e902a06d18c96a0444 Mon Sep 17 00:00:00 2001
From: Shilei Tian
Date: Sun, 12 Jan 2025 18:01:55 -0500
Subject: [PATCH] [OffloadBundler] Rework the ctor of `OffloadTargetInfo` to
suppo
arsenm wrote:
> Isn't the condition in code in terms of VecIn.size() == 2? I believe that
> VecIn is the _unique_ input elements, right? Which is distinct from the
> number of elements in the destination type? (Am I just misreading? I only
> skimmed this.)
VecIn is collecting only extract_vec
@@ -1949,6 +1949,13 @@ bool SITargetLowering::isExtractSubvectorCheap(EVT
ResVT, EVT SrcVT,
return Index == 0;
}
+bool SITargetLowering::isExtractVecEltCheap(EVT VT, unsigned Index) const {
+ // TODO: This should be more aggressive, particular for 16-bit element
+ // vect
jhuber6 wrote:
Somewhere for the linker wrapper I just checked if the triple was recognized,
you could probably just take strings after the `-` until it stops working.
https://github.com/llvm/llvm-project/pull/122629
___
llvm-branch-commits mailing li
@@ -1949,6 +1949,13 @@ bool SITargetLowering::isExtractSubvectorCheap(EVT
ResVT, EVT SrcVT,
return Index == 0;
}
+bool SITargetLowering::isExtractVecEltCheap(EVT VT, unsigned Index) const {
+ // TODO: This should be more aggressive, particular for 16-bit element
+ // vect
arsenm wrote:
> > > * BuildVector w/one non-zero non-undef source, repeated 100 times (i.e.
> > > splat or select of two splats)
> >
> >
> > I don't follow, this is a 2 element vector, how can you have 100 variants?
>
> Isn't the condition in code in terms of VecIn.size() == 2? I believe that
preames wrote:
> > * BuildVector w/one non-zero non-undef source, repeated 100 times (i.e.
> > splat or select of two splats)
>
> I don't follow, this is a 2 element vector, how can you have 100 variants?
Isn't the condition in code in terms of VecIn.size() == 2? I believe that
VecIn is the
@@ -1949,6 +1949,13 @@ bool SITargetLowering::isExtractSubvectorCheap(EVT
ResVT, EVT SrcVT,
return Index == 0;
}
+bool SITargetLowering::isExtractVecEltCheap(EVT VT, unsigned Index) const {
+ // TODO: This should be more aggressive, particular for 16-bit element
+ // vect
https://github.com/shiltian edited
https://github.com/llvm/llvm-project/pull/122629
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/jayfoad approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/122460
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/jayfoad edited
https://github.com/llvm/llvm-project/pull/122460
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/arsenm updated
https://github.com/llvm/llvm-project/pull/122672
>From acdbd89a32c585668dc6ad9797a9b7f578f84776 Mon Sep 17 00:00:00 2001
From: Matt Arsenault
Date: Fri, 10 Jan 2025 21:13:09 +0700
Subject: [PATCH] DAG: Avoid forming shufflevector from a single
extract_vector_e
https://github.com/arsenm updated
https://github.com/llvm/llvm-project/pull/122460
>From ea6a8ce50fbd64222bd897080eed662aaba15e43 Mon Sep 17 00:00:00 2001
From: Matt Arsenault
Date: Fri, 10 Jan 2025 14:57:24 +0700
Subject: [PATCH] AMDGPU: Implement isExtractVecEltCheap
Once again we have exces
arsenm wrote:
> I don't think the heuristic here is quite what you want. I believe this
> heuristic disables both of the following cases:
>
> * BuildVector w/one non-zero non-undef element
> * BuildVector w/one non-zero non-undef source, repeated 100 times (i.e. splat
> or select of two splats
lenary wrote:
I'm still happy with this, and it is for docs, so I don't think the barrier to
landing it is very high.
https://github.com/llvm/llvm-project/pull/114998
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lis
https://github.com/preames commented:
I don't think the heuristic here is quite what you want. I believe this
heuristic disables both of the following cases:
* BuildVector w/one non-zero non-undef element
* BuildVector w/one non-zero non-undef source, repeated 100 times (i.e. splat
or select o
agozillon wrote:
Small ping for some attention on this PR if at all possible please! Would be
greatly appreciated.
https://github.com/llvm/llvm-project/pull/119589
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.l
agozillon wrote:
Small ping for some attention on this PR if at all possible please! Would be
greatly appreciated.
https://github.com/llvm/llvm-project/pull/119588
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.l
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/122478
>From 8c348ba2796e08d45fe167d52db0fe047eaafa8a Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Fri, 10 Jan 2025 15:40:05 +
Subject: [PATCH 1/2] [OMPIRBuilder][MLIR] Add support for target 'if' clause
Thi
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff 364cd46360d7a5d2a79ae9bf516f23c4840ff09b
8c348ba2796e08d45fe167d52db0fe047eaafa8a --e
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/122478
>From 8c348ba2796e08d45fe167d52db0fe047eaafa8a Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Fri, 10 Jan 2025 15:40:05 +
Subject: [PATCH] [OMPIRBuilder][MLIR] Add support for target 'if' clause
This pa
https://github.com/kparzysz updated
https://github.com/llvm/llvm-project/pull/121817
>From fe3ec47965d5f970e26f9f729a21b61acf366053 Mon Sep 17 00:00:00 2001
From: Krzysztof Parzyszek
Date: Thu, 12 Dec 2024 15:26:26 -0600
Subject: [PATCH] [flang][OpenMP] Parse WHEN, OTHERWISE, MATCH clauses plus
https://github.com/HerrCai0907 updated
https://github.com/llvm/llvm-project/pull/122909
>From 9e5c5eb96a65d9bdec47566c9bf5ae95c57107f0 Mon Sep 17 00:00:00 2001
From: Congcong Cai
Date: Tue, 14 Jan 2025 22:24:46 +0800
Subject: [PATCH] [clang-tidy][NFC] refactor modernize-raw-string-literal fix
https://github.com/HerrCai0907 updated
https://github.com/llvm/llvm-project/pull/122909
>From 9e5c5eb96a65d9bdec47566c9bf5ae95c57107f0 Mon Sep 17 00:00:00 2001
From: Congcong Cai
Date: Tue, 14 Jan 2025 22:24:46 +0800
Subject: [PATCH] [clang-tidy][NFC] refactor modernize-raw-string-literal fix
llvmbot wrote:
@llvm/pr-subscribers-clang-tools-extra
Author: Congcong Cai (HerrCai0907)
Changes
---
Full diff: https://github.com/llvm/llvm-project/pull/122909.diff
2 Files Affected:
- (modified) clang-tools-extra/clang-tidy/modernize/RawStringLiteralCheck.cpp
(+62-43)
- (modified)
llvmbot wrote:
@llvm/pr-subscribers-clang-tidy
Author: Congcong Cai (HerrCai0907)
Changes
---
Full diff: https://github.com/llvm/llvm-project/pull/122909.diff
2 Files Affected:
- (modified) clang-tools-extra/clang-tidy/modernize/RawStringLiteralCheck.cpp
(+62-43)
- (modified) clang-
https://github.com/HerrCai0907 ready_for_review
https://github.com/llvm/llvm-project/pull/122909
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
HerrCai0907 wrote:
> [!WARNING]
> This pull request is not mergeable via GitHub because a downstack PR is
> open. Once all requirements are satisfied, merge this PR as a stack href="https://app.graphite.dev/github/pr/llvm/llvm-project/122909?utm_source=stack-comment-downstack-mergeability-warni
https://github.com/HerrCai0907 created
https://github.com/llvm/llvm-project/pull/122909
None
>From c413bd7b5f8d8524335ad50a71bc986d8bdca2a8 Mon Sep 17 00:00:00 2001
From: Congcong Cai
Date: Tue, 14 Jan 2025 22:24:46 +0800
Subject: [PATCH] [clang-tidy][NFC] refactor modernize-raw-string-literal
https://github.com/vhscampos updated
https://github.com/llvm/llvm-project/pull/114998
>From 7fd397e918ba2663c7342bc1653c9ccbc5be9d96 Mon Sep 17 00:00:00 2001
From: Victor Campos
Date: Tue, 5 Nov 2024 14:22:06 +
Subject: [PATCH 1/4] Add documentation for Multilib custom flags
---
clang/doc
https://github.com/vhscampos edited
https://github.com/llvm/llvm-project/pull/110659
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
kparzysz wrote:
Force-pushed to change the base. There were no review comments yes, so it
shouldn't mess up anything.
https://github.com/llvm/llvm-project/pull/121817
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lis
https://github.com/kparzysz updated
https://github.com/llvm/llvm-project/pull/121817
>From fe3ec47965d5f970e26f9f729a21b61acf366053 Mon Sep 17 00:00:00 2001
From: Krzysztof Parzyszek
Date: Thu, 12 Dec 2024 15:26:26 -0600
Subject: [PATCH] [flang][OpenMP] Parse WHEN, OTHERWISE, MATCH clauses plus
https://github.com/kparzysz edited
https://github.com/llvm/llvm-project/pull/121817
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
spavloff wrote:
Rounding mode is a parameter of a floating-point operation, its effect does not
depend on the fact that it comes from a register or is specified as an
immediate value. Implementing them differently does not look like a good
solution.
Implementing static rounding using differen
Author: David Green
Date: 2025-01-14T10:39:41+01:00
New Revision: 3bf9b25b1627ea8610c04b1ca8de4ba9ce432050
URL:
https://github.com/llvm/llvm-project/commit/3bf9b25b1627ea8610c04b1ca8de4ba9ce432050
DIFF:
https://github.com/llvm/llvm-project/commit/3bf9b25b1627ea8610c04b1ca8de4ba9ce432050.diff
L
https://github.com/tru closed https://github.com/llvm/llvm-project/pull/120505
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/tru updated https://github.com/llvm/llvm-project/pull/120505
>From 8fa5dffc865a9c9239ec0aceb3fbc801895147b7 Mon Sep 17 00:00:00 2001
From: DianQK
Date: Thu, 19 Dec 2024 06:21:57 +0800
Subject: [PATCH] [SLP] Check if instructions exist after vectorization
(#120434)
Fixes #120
Author: DianQK
Date: 2025-01-14T10:39:18+01:00
New Revision: 8fa5dffc865a9c9239ec0aceb3fbc801895147b7
URL:
https://github.com/llvm/llvm-project/commit/8fa5dffc865a9c9239ec0aceb3fbc801895147b7
DIFF:
https://github.com/llvm/llvm-project/commit/8fa5dffc865a9c9239ec0aceb3fbc801895147b7.diff
LOG: [
https://github.com/tru closed https://github.com/llvm/llvm-project/pull/121739
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
Author: Artsiom Drapun
Date: 2025-01-14T07:24:48+01:00
New Revision: f1b37b6665b5ea2b8962f11fb6d034f77a7bbd36
URL:
https://github.com/llvm/llvm-project/commit/f1b37b6665b5ea2b8962f11fb6d034f77a7bbd36
DIFF:
https://github.com/llvm/llvm-project/commit/f1b37b6665b5ea2b8962f11fb6d034f77a7bbd36.diff
59 matches
Mail list logo
