https://github.com/Fznamznon closed
https://github.com/llvm/llvm-project/pull/98629
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Fznamznon wrote:
Closing since https://github.com/llvm/llvm-project/pull/99257 fixed the problem
without side effects. Thank you very much @efriedma-quic
https://github.com/llvm/llvm-project/pull/98629
___
cfe-commits mailing list
cfe-commits@lists.l
efriedma-quic wrote:
Oh, I see, there are two checks: one for the "align" attribute, and a separate
check for the natural alignment of the type.
I'm trying out changing the limit to see how hard it actually is.
https://github.com/llvm/llvm-project/pull/98629
___
https://github.com/efriedma-quic commented:
What's the relationship between the max vector alignment, and choosing whether
to return a vector directly? As long as clang isn't emitting the byval
attribute, I don't think it's the frontend's problem.
https://github.com/llvm/llvm-project/pull/986
@@ -133,6 +133,7 @@ struct TransferrableTargetInfo {
unsigned short SuitableAlign;
unsigned short NewAlign;
unsigned MaxVectorAlign;
Fznamznon wrote:
Ok, I updated the patch to use `MaxVectorAlign` instead. Thanks
https://github.com/llvm/llvm-project/pu
https://github.com/Fznamznon updated
https://github.com/llvm/llvm-project/pull/98629
>From ba498f559c742e62c13a09cb0b909d57d986e19e Mon Sep 17 00:00:00 2001
From: "Podchishchaeva, Mariya"
Date: Fri, 12 Jul 2024 06:13:51 -0700
Subject: [PATCH 1/2] [clang] Limit alignment for emitted vectors
The
https://github.com/phoebewang edited
https://github.com/llvm/llvm-project/pull/98629
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -133,6 +133,7 @@ struct TransferrableTargetInfo {
unsigned short SuitableAlign;
unsigned short NewAlign;
unsigned MaxVectorAlign;
phoebewang wrote:
That makes sense. Passing/returning vector larger than target capacity (e.g. <4
x i64> without AVX) is
@@ -133,6 +133,7 @@ struct TransferrableTargetInfo {
unsigned short SuitableAlign;
unsigned short NewAlign;
unsigned MaxVectorAlign;
Fznamznon wrote:
I pasted log in a weird way, sorry, all failures in this particular test I see
are for Darwin.
```
// M
@@ -133,6 +133,7 @@ struct TransferrableTargetInfo {
unsigned short SuitableAlign;
unsigned short NewAlign;
unsigned MaxVectorAlign;
phoebewang wrote:
I noticed that, but the value is set for Darwin, but the failure prefix is a
non Darwin one.
https://
@@ -133,6 +133,7 @@ struct TransferrableTargetInfo {
unsigned short SuitableAlign;
unsigned short NewAlign;
unsigned MaxVectorAlign;
Fznamznon wrote:
Because `MaxVectorAlign` is set to a smaller value for some x86 targets -
https://github.com/llvm/llvm-
@@ -133,6 +133,7 @@ struct TransferrableTargetInfo {
unsigned short SuitableAlign;
unsigned short NewAlign;
unsigned MaxVectorAlign;
phoebewang wrote:
Right, sorry for the misleading. We still need to turn it to sret when vector
size > 2^14. Then why yo
efriedma-quic wrote:
> BTW, I think the limitation I'm hitting is introduced by
> https://reviews.llvm.org/D121898 .
The limitation existed before that; we just miscompiled instead of reporting an
error.
https://github.com/llvm/llvm-project/pull/98629
https://github.com/Fznamznon edited
https://github.com/llvm/llvm-project/pull/98629
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -133,6 +133,7 @@ struct TransferrableTargetInfo {
unsigned short SuitableAlign;
unsigned short NewAlign;
unsigned MaxVectorAlign;
Fznamznon wrote:
I'm not sure it will? With only modifying base TargetInfo clang will continue
emit LLVM IR where giant
@@ -133,6 +133,7 @@ struct TransferrableTargetInfo {
unsigned short SuitableAlign;
unsigned short NewAlign;
unsigned MaxVectorAlign;
phoebewang wrote:
I think set `MaxVectorAlign = 2^14` in base TargetInfo only should solve the
problem and won't result
@@ -133,6 +133,7 @@ struct TransferrableTargetInfo {
unsigned short SuitableAlign;
unsigned short NewAlign;
unsigned MaxVectorAlign;
Fznamznon wrote:
I did MaxVectorAlign = 2^14 in base TargetInfo,
```
if (Ty->getAs() &&
getContext().getType
@@ -133,6 +133,7 @@ struct TransferrableTargetInfo {
unsigned short SuitableAlign;
unsigned short NewAlign;
unsigned MaxVectorAlign;
phoebewang wrote:
I'm surprised the change of alignment affects ABI. Did you just expand
```
MaxVectorAlign =
https://github.com/Fznamznon edited
https://github.com/llvm/llvm-project/pull/98629
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Fznamznon edited
https://github.com/llvm/llvm-project/pull/98629
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Fznamznon wrote:
BTW, I think the limitation I'm hitting is introduced by
https://reviews.llvm.org/D121898 .
https://github.com/llvm/llvm-project/pull/98629
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman
@@ -133,6 +133,7 @@ struct TransferrableTargetInfo {
unsigned short SuitableAlign;
unsigned short NewAlign;
unsigned MaxVectorAlign;
Fznamznon wrote:
`MaxVectorAlign` is set for x86 targets. I can use it as a limit as well, but
note that this patch also
@@ -133,6 +133,7 @@ struct TransferrableTargetInfo {
unsigned short SuitableAlign;
unsigned short NewAlign;
unsigned MaxVectorAlign;
phoebewang wrote:
There's no special limitaion on x86. We can change ArgFlagsTy if the size is
not the concern.
https:/
@@ -133,6 +133,7 @@ struct TransferrableTargetInfo {
unsigned short SuitableAlign;
unsigned short NewAlign;
unsigned MaxVectorAlign;
efriedma-quic wrote:
It's used in the same ASTContext code that's modified by this patch. Probably
fine to adjust it fo
efriedma-quic wrote:
The size of ArgFlagsTy is, as far as I can tell, basically irrelevant: it's
only used as part of computing the calling convention in isel. I don't think
anyone will notice if it's a few bytes larger.
The non-byval alignment limit was last adjusted in
https://reviews.llvm
@@ -133,6 +133,7 @@ struct TransferrableTargetInfo {
unsigned short SuitableAlign;
unsigned short NewAlign;
unsigned MaxVectorAlign;
phoebewang wrote:
What's this used for? Can we limit it to 2^14?
https://github.com/llvm/llvm-project/pull/98629
___
phoebewang wrote:
> > max aligment [...] LLVM Verifier accepts is 2^14
>
> The verifier limit in most places is 2^32. It looks like 2^14 is specifically
> for ByVal. And there isn't really any good reason for that limit; it was
> arbitrarily chosen in
> [66011c1](https://github.com/llvm/llvm-
efriedma-quic wrote:
(The relevant bitfield is was renamed to MemAlign, and is now in
llvm/include/llvm/CodeGen/TargetCallingConv.h)
https://github.com/llvm/llvm-project/pull/98629
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.
efriedma-quic wrote:
> max aligment [...] LLVM Verifier accepts is 2^14
The verifier limit in most places is 2^32. It looks like 2^14 is specifically
for ByVal. And there isn't really any good reason for that limit; it was
arbitrarily chosen in b567e3ffb0, nearly two decades ago, and could e
llvmbot wrote:
@llvm/pr-subscribers-backend-x86
@llvm/pr-subscribers-clang
Author: Mariya Podchishchaeva (Fznamznon)
Changes
The max aligment that ISel and therefore LLVM Verifier accepts is 2^14. The
patch also forces indirect passing and returning of vectors bigger than this
limit for
llvmbot wrote:
@llvm/pr-subscribers-clang-codegen
Author: Mariya Podchishchaeva (Fznamznon)
Changes
The max aligment that ISel and therefore LLVM Verifier accepts is 2^14. The
patch also forces indirect passing and returning of vectors bigger than this
limit for generic and x86_64 target
https://github.com/Fznamznon created
https://github.com/llvm/llvm-project/pull/98629
The max aligment that ISel and therefore LLVM Verifier accepts is 2^14. The
patch also forces indirect passing and returning of vectors bigger than this
limit for generic and x86_64 targets.
>From ba498f559c7
32 matches
Mail list logo
