https://github.com/FreddyLeaf updated
https://github.com/llvm/llvm-project/pull/75580
>From e16afbdc9f0c04bad0e8f80f90c0eb26c13d3326 Mon Sep 17 00:00:00 2001
From: Freddy Ye
Date: Fri, 15 Dec 2023 16:50:23 +0800
Subject: [PATCH 1/6] [X86] Emit Warnings for frontend options to enable
knl/knm.
RKSimon wrote:
> @RKSimon @phoebewang Thanks comments! knm has AVX512_VPOPCNTDQ, I guess we
> also require it work without avx512vl? And we are going to keep
> -march/mtune/mcpu support for knl/knm, but removing some specific ISA's
> intrinsic and lowering supports? Did I get your point
FreddyLeaf wrote:
@RKSimon @phoebewang Thanks comments! knm has AVX512_VPOPCNTDQ, I guess we
also require it work without avx512vl? And we are going to keep
-march/mtune/mcpu support for knl/knm, but removing some specific ISA's
intrinsic and lowering supports? Did I get your point wrong?
RKSimon wrote:
Sorry, we'd require both avx512f and avx512cd to work without avx512vl - but
everything afterward (avx512bw, avx512dq, ) we could assume avx512vl is
enabled.
https://github.com/llvm/llvm-project/pull/75580
___
cfe-commits mailing
phoebewang wrote:
> Making avx512f the only case where avx512vl can be disabled doesn't seem like
> too much of a stretch to me - we'd be merely making all avx512 extension
> features depend on avx512vl.
Agreed.
https://github.com/llvm/llvm-project/pull/75580
RKSimon wrote:
Making avx512f the only case where avx512vl can be disabled doesn't seem like
too much of a stretch to me - we'd be merely making all avx512 extension
features depend on avx512vl.
https://github.com/llvm/llvm-project/pull/75580
___
FreddyLeaf wrote:
Keeping `-march` supports for knl/knm meanwhile removing the specific ISA's
intrinsic supports doesn't sound quite good to me. And thanks @phoebewang
mentioned, removing the KNL/KNM supports could make all other targets always
support AVX512F and AVX512VL meanwhile. This can
phoebewang wrote:
> I also think we need a policy regarding what test coverage we need for
> various avx512 features (when should we assume avx512vl etc.)
Considering the new evolution in AVX10, we should switch testing model from
`avx512xxx ± avx512vl` to `avx512xxx + avx512vl ±
evex512`.
RKSimon wrote:
I think if we have an approach that allows people to emulate a very basic
KNL/KNM implementation with the equivalent of "-march=x86-64-v3 -mavx512f
-mavx512cd" then that would be sufficient. I do think we should be keeping
-march/tune support though for the knl/knm cpu model
FreddyLeaf wrote:
ping for review
@RKSimon are we aligned on the direction to removing knl/knm supports in the
end?
https://github.com/llvm/llvm-project/pull/75580
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/FreddyLeaf updated
https://github.com/llvm/llvm-project/pull/75580
>From e16afbdc9f0c04bad0e8f80f90c0eb26c13d3326 Mon Sep 17 00:00:00 2001
From: Freddy Ye
Date: Fri, 15 Dec 2023 16:50:23 +0800
Subject: [PATCH 1/5] [X86] Emit Warnings for frontend options to enable
knl/knm.
FreddyLeaf wrote:
> Can you give me a better idea of the stages you intend to follow with this.
> The patch title suggests removing all KNL/KNM handling but the patch itself
> looks to be just about the KNL/KNM specific features.
I have created a draft PR to do removal in next release:
phoebewang wrote:
> Can you give me a better idea of the stages you intend to follow with this.
> The patch title suggests removing all KNL/KNM handling but the patch itself
> looks to be just about the KNL/KNM specific features.
>
> Removing the (incomplete) KNL/KNM specific features
RKSimon wrote:
Can you give me a better idea of the stages you intend to follow with this. The
patch title suggests removing all KNL/KNM handling but the patch itself looks
to be just about the KNL/KNM specific features.
Removing the (incomplete) KNL/KNM specific features (ER/PF/etc) I don't
https://github.com/FreddyLeaf updated
https://github.com/llvm/llvm-project/pull/75580
>From e16afbdc9f0c04bad0e8f80f90c0eb26c13d3326 Mon Sep 17 00:00:00 2001
From: Freddy Ye
Date: Fri, 15 Dec 2023 16:50:23 +0800
Subject: [PATCH 1/4] [X86] Emit Warnings for frontend options to enable
knl/knm.
@@ -349,6 +349,8 @@ def warn_invalid_feature_combination : Warning<
def warn_target_unrecognized_env : Warning<
"mismatch between architecture and environment in target triple '%0'; did
you mean '%1'?">,
InGroup;
+def warn_knl_knm_target_supports_remove : Warning<
https://github.com/FreddyLeaf updated
https://github.com/llvm/llvm-project/pull/75580
>From e16afbdc9f0c04bad0e8f80f90c0eb26c13d3326 Mon Sep 17 00:00:00 2001
From: Freddy Ye
Date: Fri, 15 Dec 2023 16:50:23 +0800
Subject: [PATCH 1/3] [X86] Emit Warnings for frontend options to enable
knl/knm.
@@ -349,6 +349,8 @@ def warn_invalid_feature_combination : Warning<
def warn_target_unrecognized_env : Warning<
"mismatch between architecture and environment in target triple '%0'; did
you mean '%1'?">,
InGroup;
+def warn_knl_knm_target_supports_remove : Warning<
https://github.com/FreddyLeaf updated
https://github.com/llvm/llvm-project/pull/75580
>From e16afbdc9f0c04bad0e8f80f90c0eb26c13d3326 Mon Sep 17 00:00:00 2001
From: Freddy Ye
Date: Fri, 15 Dec 2023 16:50:23 +0800
Subject: [PATCH 1/2] [X86] Emit Warnings for frontend options to enable
knl/knm.
KanRobert wrote:
One more justification...
https://www.felixcloutier.com/x86/vscatterpf0dps:vscatterpf0qps:vscatterpf0dpd:vscatterpf0qpd
The assembler support for some KNL instructions is buggy
phoebewang wrote:
One more reason I can think of is with KNL/KNM removal, we can simplify
supporting widen 128/256-bit vector to 512-bit without AVX512VL feature since
all reset targets support AVX512VL. The test cases can be simplified too.
https://github.com/llvm/llvm-project/pull/75580
FreddyLeaf wrote:
And here're two more reasons I collected from gcc:
1. previously ICC and ICX has removed the support and emitted errors
1. we would also like to remove the support in GCC to reduce maintainence
effort.
https://github.com/llvm/llvm-project/pull/75580
FreddyLeaf wrote:
Let me first paste reasons I listed before:
1. INTEL has officially announced these products’ EOL on about Aug. 2017
1. Even for now, clang/llvm’s supports on these products are incomplete. For
example, knm targets has AVX5124FMAPS instructions, while its intrinsic and
RKSimon wrote:
Why do you want to remove these? We don't support any of the more exotic
behaviors of Xeon Phi, but removing a x86 cpu just because its EOL doesn't make
sense to me.
https://github.com/llvm/llvm-project/pull/75580
___
cfe-commits
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Freddy Ye (FreddyLeaf)
Changes
Since Knight Landing and Knight Mill microarchitectures are EOL, we
would like to remove its support in LLVM 19. In LLVM 18, we will first
emit a warning for the usage.
---
Full diff:
https://github.com/FreddyLeaf created
https://github.com/llvm/llvm-project/pull/75580
Since Knight Landing and Knight Mill microarchitectures are EOL, we
would like to remove its support in LLVM 19. In LLVM 18, we will first
emit a warning for the usage.
>From
26 matches
Mail list logo
