@@ -5,15 +5,15 @@
// NO_GHASH-NOT: "-gcodeview-ghash"
// default
-// RUN: %clang_cl /Z7 -### -- %s 2>&1 | FileCheck -check-prefix=NO_GHASH %s
+// RUN: %clang_cl -target x86_64-windows /Z7 -### -- %s 2>&1 | FileCheck
-check-prefix=NO_GHASH %s
// enabled
-// RUN: %clang_cl /Z7
https://github.com/phoebewang closed
https://github.com/llvm/llvm-project/pull/88245
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2,12 +2,20 @@
// RUN: %clang_cc1 -E -triple i386 -dM -o - -fcf-protection=branch %s |
FileCheck %s --check-prefix=BRANCH
// RUN: %clang_cc1 -E -triple i386 -dM -o - -fcf-protection=full %s |
FileCheck %s --check-prefix=FULL
// RUN: not %clang_cc1 -emit-llvm-only -triple
@@ -2,12 +2,20 @@
// RUN: %clang_cc1 -E -triple i386 -dM -o - -fcf-protection=branch %s |
FileCheck %s --check-prefix=BRANCH
// RUN: %clang_cc1 -E -triple i386 -dM -o - -fcf-protection=full %s |
FileCheck %s --check-prefix=FULL
// RUN: not %clang_cc1 -emit-llvm-only -triple
https://github.com/phoebewang edited
https://github.com/llvm/llvm-project/pull/88736
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/phoebewang edited
https://github.com/llvm/llvm-project/pull/88736
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/phoebewang closed
https://github.com/llvm/llvm-project/pull/88101
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
phoebewang wrote:
Thanks a lot @nico! I see the bot is still red, but not failed on this test any
more.
https://github.com/llvm/llvm-project/pull/88101
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/list
@@ -1,13 +1,22 @@
// RUN: %clang_cc1 -E -triple i386 -dM -o - -fcf-protection=return %s |
FileCheck %s --check-prefix=RETURN
// RUN: %clang_cc1 -E -triple i386 -dM -o - -fcf-protection=branch %s |
FileCheck %s --check-prefix=BRANCH
// RUN: %clang_cc1 -E -triple i386 -dM -o -
@@ -1,13 +1,22 @@
// RUN: %clang_cc1 -E -triple i386 -dM -o - -fcf-protection=return %s |
FileCheck %s --check-prefix=RETURN
// RUN: %clang_cc1 -E -triple i386 -dM -o - -fcf-protection=branch %s |
FileCheck %s --check-prefix=BRANCH
// RUN: %clang_cc1 -E -triple i386 -dM -o -
https://github.com/phoebewang approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/88736
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/phoebewang edited
https://github.com/llvm/llvm-project/pull/88736
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/phoebewang closed
https://github.com/llvm/llvm-project/pull/88736
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
phoebewang wrote:
Sorry, I know nothing about it. But it looks to me it's to match with GCC, why
don't borrow the value from GCC as a beginning?
https://github.com/llvm/llvm-project/pull/89446
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
ht
@@ -58173,8 +58173,8 @@ X86TargetLowering::getSingleConstraintMatchWeight(
return CW_Invalid;
// Any MMX reg
case 'm':
- if (Ty->isX86_MMXTy() && Subtarget.hasMMX())
-return Wt;
+ if (Ty->getPrimitiveSizeInBits() == 64 && Subtarget.hasMMX())
phoebewang wrote:
I'm good with adding the macro. But how it propagates to other compilers would
be an chicken or the egg problem. User won't use this flag if they care the
portability, while other compilers may be reluctant to add it if no requiest
from their user.
https://github.com/llvm/ll
@@ -1185,6 +1189,9 @@ Currently, only the following parameter attributes are
defined:
value should be sign-extended to the extent required by the target's
ABI (which is usually 32-bits) by the caller (for a parameter) or
the callee (for a return value).
+``noext``
@@ -1185,6 +1189,9 @@ Currently, only the following parameter attributes are
defined:
value should be sign-extended to the extent required by the target's
ABI (which is usually 32-bits) by the caller (for a parameter) or
the callee (for a return value).
+``noext``
https://github.com/phoebewang edited
https://github.com/llvm/llvm-project/pull/100757
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/phoebewang approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/101151
___
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:
Right, sorry for the misleading. We still need to turn it to sret when vector
size > 2^14. Then why yo
@@ -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;
phoebewang wrote:
That makes sense. Passing/returning vector larger than target capacity (e.g. <4
x i64> without AVX) is
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
@@ -175,8 +175,6 @@ X86_FEATURE_COMPAT(AVX512BF16, "avx512bf16",
34)
X86_FEATURE_COMPAT(AVX512VP2INTERSECT, "avx512vp2intersect", 35)
// Below Features has some missings comparing to gcc, it's because gcc has some
// not one-to-one mapped in llvm.
-X86_FEATURE_
https://github.com/phoebewang approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/99352
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -175,8 +175,6 @@ X86_FEATURE_COMPAT(AVX512BF16, "avx512bf16",
34)
X86_FEATURE_COMPAT(AVX512VP2INTERSECT, "avx512vp2intersect", 35)
// Below Features has some missings comparing to gcc, it's because gcc has some
// not one-to-one mapped in llvm.
-X86_FEATURE_
phoebewang wrote:
What's the ties mean here? The SDM uses `Round to nearest (even)`. As for
target intrinsic, I think we sholuld be close to target document. Also, will
GCC accept the name? We need compatibility with GCC, or even MSVC.
https://github.com/llvm/llvm-project/pull/99691
__
phoebewang wrote:
Thanks @hpkfft for the thorough explanation. I'm fine with either
`_MM_FROUND_TIES_TO_EVEN` or `_MM_FROUND_TO_NEAREST_TIES_EVEN`. Let's see GCC
community preference.
https://github.com/llvm/llvm-project/pull/99691
___
cfe-commits ma
phoebewang wrote:
> I am curious what a `win32-elf` triple is. Does MSVC support generating ELF
> object files?
No idea, but https://github.com/llvm/llvm-project/issues/87140 doesn't look
like from fuzzing.
Consider Windows has WSL now, I'd not surprise it's supported or will be
supported som
https://github.com/phoebewang updated
https://github.com/llvm/llvm-project/pull/88245
>From 569c7dfee58f7e4357d8af45b52a3135cb4e2e65 Mon Sep 17 00:00:00 2001
From: Phoebe Wang
Date: Wed, 10 Apr 2024 15:38:49 +0800
Subject: [PATCH 1/3] "Reland "[Win32][ELF] Make CodeView a DebugInfoFormat
only
https://github.com/phoebewang updated
https://github.com/llvm/llvm-project/pull/88245
>From 569c7dfee58f7e4357d8af45b52a3135cb4e2e65 Mon Sep 17 00:00:00 2001
From: Phoebe Wang
Date: Wed, 10 Apr 2024 15:38:49 +0800
Subject: [PATCH 1/3] "Reland "[Win32][ELF] Make CodeView a DebugInfoFormat
only
https://github.com/phoebewang updated
https://github.com/llvm/llvm-project/pull/88245
>From 569c7dfee58f7e4357d8af45b52a3135cb4e2e65 Mon Sep 17 00:00:00 2001
From: Phoebe Wang
Date: Wed, 10 Apr 2024 15:38:49 +0800
Subject: [PATCH 1/3] "Reland "[Win32][ELF] Make CodeView a DebugInfoFormat
only
https://github.com/phoebewang updated
https://github.com/llvm/llvm-project/pull/88245
>From 569c7dfee58f7e4357d8af45b52a3135cb4e2e65 Mon Sep 17 00:00:00 2001
From: Phoebe Wang
Date: Wed, 10 Apr 2024 15:38:49 +0800
Subject: [PATCH 1/3] "Reland "[Win32][ELF] Make CodeView a DebugInfoFormat
only
https://github.com/phoebewang updated
https://github.com/llvm/llvm-project/pull/88245
>From 569c7dfee58f7e4357d8af45b52a3135cb4e2e65 Mon Sep 17 00:00:00 2001
From: Phoebe Wang
Date: Wed, 10 Apr 2024 15:38:49 +0800
Subject: [PATCH 1/3] "Reland "[Win32][ELF] Make CodeView a DebugInfoFormat
only
https://github.com/phoebewang updated
https://github.com/llvm/llvm-project/pull/88245
>From 569c7dfee58f7e4357d8af45b52a3135cb4e2e65 Mon Sep 17 00:00:00 2001
From: Phoebe Wang
Date: Wed, 10 Apr 2024 15:38:49 +0800
Subject: [PATCH 1/3] "Reland "[Win32][ELF] Make CodeView a DebugInfoFormat
only
phoebewang wrote:
> For driver tests we prefer specifying a concrete target triple than making a
> test dependent on the default target triple (controlled by `REQUIES:
> coff-supported-target` in this case).
>
> A concrete target triple (e.g. x86_64-windows) loses coverage for
> aarch64-windo
https://github.com/phoebewang approved this pull request.
LGTM, thanks!
https://github.com/llvm/llvm-project/pull/105852
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -45,6 +45,14 @@ bool SemaX86::CheckBuiltinRoundingOrSAE(unsigned BuiltinID,
CallExpr *TheCall) {
case X86::BI__builtin_ia32_vcvttsh2si64:
phoebewang wrote:
We don't have a VCVTTSH2SIS instruction. The general convention is to use the
instruction name dire
@@ -910,3 +910,313 @@ multiclass avx10_convert_2op_nomb,
AVX512XDIi8Base, T_MAP5, EVEX, EVEX_CD8<16, CD8VH>;
+
+//-
+// AVX10 BF16 instructions
+//-
+
+// VADDNEPBF16
@@ -910,3 +910,313 @@ multiclass avx10_convert_2op_nomb,
AVX512XDIi8Base, T_MAP5, EVEX, EVEX_CD8<16, CD8VH>;
+
+//-
+// AVX10 BF16 instructions
+//-
+
+// VADDNEPBF16
@@ -910,3 +910,313 @@ multiclass avx10_convert_2op_nomb,
AVX512XDIi8Base, T_MAP5, EVEX, EVEX_CD8<16, CD8VH>;
+
+//-
+// AVX10 BF16 instructions
+//-
+
+// VADDNEPBF16
@@ -910,3 +910,313 @@ multiclass avx10_convert_2op_nomb,
AVX512XDIi8Base, T_MAP5, EVEX, EVEX_CD8<16, CD8VH>;
+
+//-
+// AVX10 BF16 instructions
+//-
+
+// VADDNEPBF16
@@ -910,3 +910,313 @@ multiclass avx10_convert_2op_nomb,
AVX512XDIi8Base, T_MAP5, EVEX, EVEX_CD8<16, CD8VH>;
+
+//-
+// AVX10 BF16 instructions
+//-
+
+// VADDNEPBF16
@@ -0,0 +1,1054 @@
+// RUN: %clang_cc1 -flax-vector-conversions=none -ffreestanding %s
-triple=x86_64 -target-feature +avx10.2-512 -emit-llvm -o -
-Wno-invalid-feature-combination -Wall -Werror | FileCheck %s
+// RUN: %clang_cc1 -flax-vector-conversions=none -ffreestanding %s
-
@@ -0,0 +1,565 @@
+/*===--- avx10_2_512bf16intrin.h - AVX10-BF16 intrinsics -===
+ *
+ * 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
@@ -14836,6 +14837,9 @@ Value *CodeGenFunction::EmitX86BuiltinExpr(unsigned
BuiltinID,
case X86::BI__builtin_ia32_vfmaddph512_mask:
case X86::BI__builtin_ia32_vfmaddph512_maskz:
case X86::BI__builtin_ia32_vfmaddph512_mask3:
+ case X86::BI__builtin_ia32_vfmaddnepbh128:
+
@@ -910,3 +910,313 @@ multiclass avx10_convert_2op_nomb,
AVX512XDIi8Base, T_MAP5, EVEX, EVEX_CD8<16, CD8VH>;
+
+//-
+// AVX10 BF16 instructions
+//-
+
+// VADDNEPBF16
@@ -7219,3 +7219,413 @@ def int_x86_avx10_mask_vcvtneph2hf8s512 :
ClangBuiltin<"__builtin_ia32_vcvtneph2
DefaultAttrsIntrinsic<[llvm_v32i8_ty], [llvm_v32f16_ty, llvm_v32i8_ty,
llvm_i32_ty],
[IntrNoMem]>;
}
+
+//===
@@ -910,3 +910,313 @@ multiclass avx10_convert_2op_nomb,
AVX512XDIi8Base, T_MAP5, EVEX, EVEX_CD8<16, CD8VH>;
+
+//-
+// AVX10 BF16 instructions
+//-
+
+// VADDNEPBF16
@@ -910,3 +910,313 @@ multiclass avx10_convert_2op_nomb,
AVX512XDIi8Base, T_MAP5, EVEX, EVEX_CD8<16, CD8VH>;
+
+//-
+// AVX10 BF16 instructions
+//-
+
+// VADDNEPBF16
@@ -910,3 +910,313 @@ multiclass avx10_convert_2op_nomb,
AVX512XDIi8Base, T_MAP5, EVEX, EVEX_CD8<16, CD8VH>;
+
+//-
+// AVX10 BF16 instructions
+//-
+
+// VADDNEPBF16
@@ -147,11 +147,13 @@ set(x86_files
amxcomplexintrin.h
amxfp16intrin.h
amxintrin.h
+ avx10_2_512bf16intrin.h
avx10_2_512convertintrin.h
avx10_2_512minmaxintrin.h
avx10_2_512niintrin.h
avx10_2_512satcvtintrin.h
avx10_2convertintrin.h
+ avx10_2bf16intrin.h
@@ -313,7 +313,7 @@ def v32i16_info : X86VectorVTInfo<32, i16, VR512, "w">;
def v16i32_info : X86VectorVTInfo<16, i32, VR512, "d">;
def v8i64_info : X86VectorVTInfo<8, i64, VR512, "q">;
def v32f16_info : X86VectorVTInfo<32, f16, VR512, "ph">;
-def v32bf16_info: X86VectorVTInf
@@ -211,6 +211,12 @@ def X86CmpMaskCC :
SDTypeProfile<1, 3, [SDTCisVec<0>, SDTCVecEltisVT<0, i1>,
SDTCisVec<1>, SDTCisSameAs<2, 1>,
SDTCisSameNumEltsAs<0, 1>, SDTCisVT<3, i8>]>;
+
+def X86CmpMaskCC_Int :
+ SDTypeProfile<1
phoebewang wrote:
Should we add folding in X86InstrFMA3Info.cpp?
https://github.com/llvm/llvm-project/pull/101603
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/phoebewang approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/101603
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/phoebewang edited
https://github.com/llvm/llvm-project/pull/101603
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -153,7 +163,8 @@ const X86InstrFMA3Group *llvm::getFMA3Group(unsigned
Opcode, uint64_t TSFlags) {
((TSFlags & X86II::EncodingMask) == X86II::EVEX &&
((TSFlags & X86II::OpMapMask) == X86II::T8 ||
(TSF
phoebewang wrote:
> You can see from this example that when C++ rules force the use of an sret
> indirect return, a register is consumed:
> https://godbolt.org/z/W3fdn8s5Y
Could you explain more about the example? I didn't find where the register
consumed. Don't both `copy_trivial` and `copy_n
@@ -15,21 +15,22 @@
#include "llvm/Support/raw_ostream.h"
#include "llvm/TargetParser/Host.h"
+#include
+
phoebewang wrote:
Not needed.
https://github.com/llvm/llvm-project/pull/97824
___
cfe-commits mailing list
@@ -13,6 +13,7 @@
#ifndef LLVM_TARGETPARSER_HOST_H
#define LLVM_TARGETPARSER_HOST_H
+#include
phoebewang wrote:
ditto
https://github.com/llvm/llvm-project/pull/97824
___
cfe-commits mailing list
cfe-commits@lists.
https://github.com/phoebewang approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/97824
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
phoebewang wrote:
> I lost the `__fastcall` or `__vectorcall` during editing, here's a fixed
> link: https://godbolt.org/z/46j33z8bc
>
> You can see the load from [edx] and store to [ecx]:
>
> ```
> NonTrivial copy_nontrivial(NonTrivial *) PROC ; copy_nontrivial, COMDAT
> mov eax
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-
@@ -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
___
@@ -38,11 +38,11 @@ int test4(volatile int *addr) {
return (int)oldval;
}
-// This should have both inputs be of type x86_mmx.
+// This should have both inputs be of type <1 x i64>.
phoebewang wrote:
Does it conflict with comment in mmx-inlineasm.ll
> Veri
@@ -44,8 +44,8 @@ Type *Type::getPrimitiveType(LLVMContext &C, TypeID IDNumber)
{
case FP128TyID : return getFP128Ty(C);
case PPC_FP128TyID : return getPPC_FP128Ty(C);
case LabelTyID : return getLabelTy(C);
- case MetadataTyID : return getMetadataTy(C);
- case
@@ -57594,6 +57599,86 @@ static SDValue combinePDEP(SDNode *N, SelectionDAG
&DAG,
return SDValue();
}
+// Fixup the MMX intrinsics' types: in IR they are expressed with <1 x i64>,
phoebewang wrote:
Are we able to do it in DAGtoDAG?
https://github.com/llvm
@@ -1,9 +0,0 @@
-; RUN: llvm-as < %s | llvm-dis | FileCheck %s
-; RUN: verify-uselistorder %s
-; Basic smoke test for x86_mmx type.
-
-; CHECK: define x86_mmx @sh16
phoebewang wrote:
What will it be after this patch?
https://github.com/llvm/llvm-project/pull/985
https://github.com/phoebewang approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/96246
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/phoebewang approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/96540
___
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:
There's no special limitaion on x86. We can change ArgFlagsTy if the size is
not the concern.
https:/
@@ -1,9 +0,0 @@
-; RUN: llvm-as < %s | llvm-dis | FileCheck %s
-; RUN: verify-uselistorder %s
-; Basic smoke test for x86_mmx type.
-
-; CHECK: define x86_mmx @sh16
phoebewang wrote:
Why we removed it instead of update?
https://github.com/llvm/llvm-project/pull/
@@ -57594,6 +57599,86 @@ static SDValue combinePDEP(SDNode *N, SelectionDAG
&DAG,
return SDValue();
}
+// Fixup the MMX intrinsics' types: in IR they are expressed with <1 x i64>,
phoebewang wrote:
Can we use `i64` instead of `<1 x i64>` given we don't car
@@ -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 =
@@ -57594,6 +57599,86 @@ static SDValue combinePDEP(SDNode *N, SelectionDAG
&DAG,
return SDValue();
}
+// Fixup the MMX intrinsics' types: in IR they are expressed with <1 x i64>,
phoebewang wrote:
Right. I forgot the 32bit case.
https://github.com/llvm/l
@@ -94,14 +94,15 @@ entry:
;
; MMX Store
+; Note: doesn't actually emit a non-temporal store here.
;
define void @test_mmx(ptr nocapture %a0, ptr nocapture %a1) {
; ALL-LABEL: test_mmx:
; ALL: # %bb.0: # %entry
; ALL-NEXT:movq (%rdi), %mm0
; ALL-NEXT:psrl
@@ -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
https://github.com/phoebewang closed
https://github.com/llvm/llvm-project/pull/88245
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/phoebewang reopened
https://github.com/llvm/llvm-project/pull/88245
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown %s -o /dev/null
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-feature +egpr %s -o
/dev/null
+
+int foo(void) {
+ register int a __asm__("ebx");
+#ifdef __EGPR__
phoebewang wrote:
W
https://github.com/phoebewang edited
https://github.com/llvm/llvm-project/pull/91323
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/phoebewang created
https://github.com/llvm/llvm-project/pull/91694
…et doesn't support AVX512
Users want `-march=sandybridge -mavx512f -mavx512vl` behaves the same as
`-march=native -mavx512f -mavx512vl` on a sandybridge target.
Fixes: #91076
>From 6ea15aa0ee6726cad8dccff1
https://github.com/phoebewang edited
https://github.com/llvm/llvm-project/pull/91694
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/phoebewang edited
https://github.com/llvm/llvm-project/pull/91694
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/phoebewang updated
https://github.com/llvm/llvm-project/pull/91694
>From 6ea15aa0ee6726cad8dccff10155f058afa0f013 Mon Sep 17 00:00:00 2001
From: Phoebe Wang
Date: Fri, 10 May 2024 11:21:41 +0800
Subject: [PATCH 1/2] [X86][Driver] Do not add `-evex512` for `-march=native`
whe
phoebewang wrote:
> Could you make getHostCPUFeatures only write the Features["evex512"] entry if
> Features["avx512f"] is true? Instead of copying Features["avx512f"]?
Good idea, done.
https://github.com/llvm/llvm-project/pull/91694
___
cfe-commits
https://github.com/phoebewang closed
https://github.com/llvm/llvm-project/pull/91694
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/phoebewang milestoned
https://github.com/llvm/llvm-project/pull/91694
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
phoebewang wrote:
/cherry-pick
https://github.com/llvm/llvm-project/commit/87f3407856e61a73798af4e41b28bc33b5bf4ce6
https://github.com/llvm/llvm-project/pull/91694
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
https://github.com/phoebewang created
https://github.com/llvm/llvm-project/pull/91846
This is how MSVC handles it. https://godbolt.org/z/fG386bjnf
>From 844fb5283d654d7d9cb68c5712b338f0a70b384e Mon Sep 17 00:00:00 2001
From: Phoebe Wang
Date: Sat, 11 May 2024 16:07:00 +0800
Subject: [PATCH] [X
https://github.com/phoebewang updated
https://github.com/llvm/llvm-project/pull/91846
>From 844fb5283d654d7d9cb68c5712b338f0a70b384e Mon Sep 17 00:00:00 2001
From: Phoebe Wang
Date: Sat, 11 May 2024 16:07:00 +0800
Subject: [PATCH 1/2] [X86][vectorcall] Pass built types byval when xmm0~6
exhaus
@@ -792,7 +792,7 @@ ABIArgInfo X86_32ABIInfo::classifyArgumentType(QualType Ty,
CCState &State,
return ABIArgInfo::getDirect();
return ABIArgInfo::getExpand();
}
-return getIndirectResult(Ty, /*ByVal=*/false, State);
+return getIndirectResult(Ty, IsVe
phoebewang wrote:
> @tstellar Can a note be added somewhere about this? Folks upgrading to
> llvm-18.1.6 will get errors unless they drop -march=native if they were on
> 18.1.5
Although I agree we should add a note, I don't think this patch affects much.
The problem only coccurs when combinin
phoebewang wrote:
@FireBurn Sorry, I just noticed #91719. The above comments were based on the
issue #91076.
I didn't look at the source, but the command line doesn't have an AVX512
option. So I'm assuming the code may related function multi-versioning with
manually specified target attribute
phoebewang wrote:
> You'll be probably building 18.1.6 with 18.1.5... and that's when you'll
> notice the issue. I'm just about finished building 18.1.5 with your patch. So
> hopefully all those issues will be gone. I'll report back
Okay... This is a combined problem which I never thought befo
https://github.com/phoebewang closed
https://github.com/llvm/llvm-project/pull/91846
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
phoebewang wrote:
Ping?
https://github.com/llvm/llvm-project/pull/88245
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
phoebewang wrote:
> @phoebewang Can you add a release note for this on the PR for the release
> branch and then add the release:note label.
Done.
https://github.com/llvm/llvm-project/pull/91694
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
401 - 500 of 965 matches
Mail list logo
