[X86] Emit Warnings for frontend options to enable knl/knm specific ISAs. #75580

FreddyLeaf · 2023-12-15T09:25:25Z

Since Knight Landing and Knight Mill microarchitectures are EOL, we
would like to remove intrinsic supports for its specific ISA in LLVM 19.
In LLVM 18, we will first emit a warning for the usage.

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.

llvmbot · 2023-12-15T09:25:52Z

@llvm/pr-subscribers-backend-x86
@llvm/pr-subscribers-clang-driver

@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/llvm/llvm-project/pull/75580.diff

7 Files Affected:

(modified) clang/include/clang/Basic/DiagnosticCommonKinds.td (+2)
(modified) clang/lib/Basic/Targets/X86.cpp (+3)
(modified) clang/test/CodeGen/X86/avx512er-builtins.c (+1-1)
(modified) clang/test/CodeGen/X86/avx512pf-builtins.c (+1-1)
(modified) clang/test/Driver/cl-x86-flags.c (+8-2)
(modified) clang/test/Frontend/x86-target-cpu.c (+8-2)
(modified) clang/test/Misc/warning-flags.c (+2-1)

diff --git a/clang/include/clang/Basic/DiagnosticCommonKinds.td b/clang/include/clang/Basic/DiagnosticCommonKinds.td
index 65a33f61a6948a..40841e9df547bc 100644
--- a/clang/include/clang/Basic/DiagnosticCommonKinds.td
+++ b/clang/include/clang/Basic/DiagnosticCommonKinds.td
@@ -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<InvalidCommandLineArgument>;
+def warn_knl_knm_target_supports_remove : Warning<
+  "KNL/KNM's feature support will be removed in LLVM 19.">;
 
 // Source manager
 def err_cannot_open_file : Error<"cannot open file '%0': %1">, DefaultFatal;
diff --git a/clang/lib/Basic/Targets/X86.cpp b/clang/lib/Basic/Targets/X86.cpp
index b97f88647fa49f..dc56524d378104 100644
--- a/clang/lib/Basic/Targets/X86.cpp
+++ b/clang/lib/Basic/Targets/X86.cpp
@@ -295,11 +295,13 @@ bool X86TargetInfo::handleTargetFeatures(std::vector<std::string> &Features,
       HasAVX512BF16 = true;
     } else if (Feature == "+avx512er") {
       HasAVX512ER = true;
+      Diags.Report(diag::warn_knl_knm_target_supports_remove);
     } else if (Feature == "+avx512fp16") {
       HasAVX512FP16 = true;
       HasLegalHalfType = true;
     } else if (Feature == "+avx512pf") {
       HasAVX512PF = true;
+      Diags.Report(diag::warn_knl_knm_target_supports_remove);
     } else if (Feature == "+avx512dq") {
       HasAVX512DQ = true;
     } else if (Feature == "+avx512bitalg") {
@@ -358,6 +360,7 @@ bool X86TargetInfo::handleTargetFeatures(std::vector<std::string> &Features,
       HasPREFETCHI = true;
     } else if (Feature == "+prefetchwt1") {
       HasPREFETCHWT1 = true;
+      Diags.Report(diag::warn_knl_knm_target_supports_remove);
     } else if (Feature == "+clzero") {
       HasCLZERO = true;
     } else if (Feature == "+cldemote") {
diff --git a/clang/test/CodeGen/X86/avx512er-builtins.c b/clang/test/CodeGen/X86/avx512er-builtins.c
index ee31236a3c01aa..11ec6aabec1e3f 100644
--- a/clang/test/CodeGen/X86/avx512er-builtins.c
+++ b/clang/test/CodeGen/X86/avx512er-builtins.c
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -flax-vector-conversions=none -ffreestanding %s -triple=x86_64-apple-darwin -target-feature +avx512f -target-feature +avx512er -emit-llvm -o - -Wall -Werror | FileCheck %s
+// RUN: %clang_cc1 -flax-vector-conversions=none -ffreestanding %s -triple=x86_64-apple-darwin -target-feature +avx512f -target-feature +avx512er -emit-llvm -o - -Wall | FileCheck %s
 
 
 #include <immintrin.h>
diff --git a/clang/test/CodeGen/X86/avx512pf-builtins.c b/clang/test/CodeGen/X86/avx512pf-builtins.c
index 4ca70f5787968b..3a117ed6a9460e 100644
--- a/clang/test/CodeGen/X86/avx512pf-builtins.c
+++ b/clang/test/CodeGen/X86/avx512pf-builtins.c
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -flax-vector-conversions=none -ffreestanding %s -triple=x86_64-apple-darwin -target-feature +avx512pf -emit-llvm -o - -Wall -Werror | FileCheck %s
+// RUN: %clang_cc1 -flax-vector-conversions=none -ffreestanding %s -triple=x86_64-apple-darwin -target-feature +avx512pf -emit-llvm -o - -Wall | FileCheck %s
 
 
 #include <immintrin.h>
diff --git a/clang/test/Driver/cl-x86-flags.c b/clang/test/Driver/cl-x86-flags.c
index 51b16f0ce35463..ae35a312fe8a4b 100644
--- a/clang/test/Driver/cl-x86-flags.c
+++ b/clang/test/Driver/cl-x86-flags.c
@@ -69,7 +69,10 @@
 // RUN: %clang_cl -m32 -arch:avx2 --target=i386-pc-windows -### -- 2>&1 %s | FileCheck -check-prefix=avx2 %s
 // avx2: invalid /arch: argument
 
-// RUN: %clang_cl -m32 -arch:AVX512F --target=i386-pc-windows /c /Fo%t.obj -Xclang -verify -DTEST_32_ARCH_AVX512F -- %s
+// RUN: %clang_cl -m32 -arch:AVX512F --target=i386-pc-windows /c /Fo%t.obj -Xclang -verify=KNL1 -DTEST_32_ARCH_AVX512F -- %s
+// KNL1-warning@*:* {{KNL/KNM's feature support will be removed in LLVM 19.}}
+// KNL1-warning@*:* {{KNL/KNM's feature support will be removed in LLVM 19.}}
+// KNL1-warning@*:* {{KNL/KNM's feature support will be removed in LLVM 19.}}
 #if defined(TEST_32_ARCH_AVX512F)
 #if _M_IX86_FP != 2 || !__AVX__ || !__AVX2__ || !__AVX512F__  || __AVX512BW__
 #error fail
@@ -109,7 +112,10 @@
 // RUN: %clang_cl -m64 -arch:avx2 --target=x86_64-pc-windows -### -- 2>&1 %s | FileCheck -check-prefix=avx264 %s
 // avx264: invalid /arch: argument
 
-// RUN: %clang_cl -m64 -arch:AVX512F --target=i386-pc-windows /c /Fo%t.obj -Xclang -verify -DTEST_64_ARCH_AVX512F -- %s
+// RUN: %clang_cl -m64 -arch:AVX512F --target=i386-pc-windows /c /Fo%t.obj -Xclang -verify=KNL2 -DTEST_64_ARCH_AVX512F -- %s
+// KNL2-warning@*:* {{KNL/KNM's feature support will be removed in LLVM 19.}}
+// KNL2-warning@*:* {{KNL/KNM's feature support will be removed in LLVM 19.}}
+// KNL2-warning@*:* {{KNL/KNM's feature support will be removed in LLVM 19.}}
 #if defined(TEST_64_ARCH_AVX512F)
 #if _M_IX86_FP || !__AVX__ || !__AVX2__ || !__AVX512F__  || __AVX512BW__
 #error fail
diff --git a/clang/test/Frontend/x86-target-cpu.c b/clang/test/Frontend/x86-target-cpu.c
index 6c8502ac2c21ee..be57b3c0ec583b 100644
--- a/clang/test/Frontend/x86-target-cpu.c
+++ b/clang/test/Frontend/x86-target-cpu.c
@@ -15,8 +15,14 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu cannonlake -verify %s
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu icelake-client -verify %s
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu icelake-server -verify %s
-// RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu knl -verify %s
-// RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu knm -verify %s
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu knl -verify=knl %s
+// knl-warning@*:* {{KNL/KNM's feature support will be removed in LLVM 19.}}
+// knl-warning@*:* {{KNL/KNM's feature support will be removed in LLVM 19.}}
+// knl-warning@*:* {{KNL/KNM's feature support will be removed in LLVM 19.}}
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu knm -verify=knm %s
+// knm-warning@*:* {{KNL/KNM's feature support will be removed in LLVM 19.}}
+// knm-warning@*:* {{KNL/KNM's feature support will be removed in LLVM 19.}}
+// knm-warning@*:* {{KNL/KNM's feature support will be removed in LLVM 19.}}
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu bonnell -verify %s
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu silvermont -verify %s
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu k8 -verify %s
diff --git a/clang/test/Misc/warning-flags.c b/clang/test/Misc/warning-flags.c
index c587337da5933a..f580445b1f10b9 100644
--- a/clang/test/Misc/warning-flags.c
+++ b/clang/test/Misc/warning-flags.c
@@ -18,7 +18,7 @@ This test serves two purposes:
 
 The list of warnings below should NEVER grow.  It should gradually shrink to 0.
 
-CHECK: Warnings without flags (65):
+CHECK: Warnings without flags (66):
 
 CHECK-NEXT:   ext_expected_semi_decl_list
 CHECK-NEXT:   ext_explicit_specialization_storage_class
@@ -56,6 +56,7 @@ CHECK-NEXT:   warn_ignoring_ftabstop_value
 CHECK-NEXT:   warn_implements_nscopying
 CHECK-NEXT:   warn_incompatible_qualified_id
 CHECK-NEXT:   warn_invalid_asm_cast_lvalue
+CHECK-NEXT:   warn_knl_knm_target_supports_remove
 CHECK-NEXT:   warn_maynot_respond
 CHECK-NEXT:   warn_method_param_redefinition
 CHECK-NEXT:   warn_missing_case_for_condition

RKSimon · 2023-12-15T09:51:14Z

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.

FreddyLeaf · 2023-12-15T11:05:07Z

Let me first paste reasons I listed before:

INTEL has officially announced these products’ EOL on about Aug. 2017
Even for now, clang/llvm’s supports on these products are incomplete. For example, knm targets has AVX5124FMAPS instructions, while its intrinsic and assembly support is missing. And it is weird that avx5124fmaps is still listed at llvm/include/llvm/TargetParser/X86TargetParser.def.
It sometimes leads to bad performance by wrong usage of options.
We can claim this change on release notes to notify users intentionally support these targets to use older releases.

FreddyLeaf · 2023-12-15T11:08:01Z

And here're two more reasons I collected from gcc:

previously ICC and ICX has removed the support and emitted errors
we would also like to remove the support in GCC to reduce maintainence effort.

phoebewang · 2023-12-15T12:38:14Z

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.

KanRobert · 2023-12-18T02:31:23Z

One more justification...
https://www.felixcloutier.com/x86/vscatterpf0dps:vscatterpf0qps:vscatterpf0dpd:vscatterpf0qpd

The assembler support for some KNL instructions is buggy

llvm-project/llvm/test/MC/X86/apx/evex-format-intel.s

Line 46 in 31429e7

## AsmParser is buggy for this KNC instruction

If we deprecate KNL, the bug can go away.

clang/include/clang/Basic/DiagnosticCommonKinds.td

RKSimon · 2023-12-19T12:47:51Z

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 think will be any major cause for concern, ideally we'd keep support at the assembly level only (which has been suggested for MMX as well at some point). But even that might not be necessary.

But what do you expect to happen if a KNL workstation attempts to use clang 19 with -march=native? Do we still enable it as a AVX512F+AVX512CD target or are you suggesting we degrade it to match x86-64-v3 arch spec?

How can the test cases then can be simplified? Are you suggesting that we merge more of the AVX512 attributes in X86.td (e.g. AVX512VL always enables BW/DQ / VBMI2 enables VBMI etc?).

phoebewang · 2023-12-19T14:50:28Z

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 think will be any major cause for concern, ideally we'd keep support at the assembly level only (which has been suggested for MMX as well at some point). But even that might not be necessary.

It's a good idea to preserve the assembly level support. I think GCC's proposal just wants to deprecate GCC support rather than remove support from binutils too.

But what do you expect to happen if a KNL workstation attempts to use clang 19 with -march=native? Do we still enable it as a AVX512F+AVX512CD target or are you suggesting we degrade it to match x86-64-v3 arch spec?

There're discussions in GCC mailing loop about -mtune/arch=knl. IIUC, the final decision is to remove the march support too. For -march=native, I'm not sure whether we detect it by CPU model or feature list. For the former, we didn't remove the KNL/KNM model, we can emit error for it; for the latter, we can return an approaching target has the same (remaining) features.

How can the test cases then can be simplified? Are you suggesting that we merge more of the AVX512 attributes in X86.td (e.g. AVX512VL always enables BW/DQ / VBMI2 enables VBMI etc?).

I think we can't make AVX512VL being implied by default, but can gradually relax a lot of Subtarget.hasVLX() in CPP and TD files. We don't need to test the combinations that have AVX512 features but no AVX512VL and remove them from existing tests gradually.

From the developmental trend of HW design, I don't think we will fall back to support 512-bit only features in the future. So from my point of view, simplifying backend design and testing would be the major benefit we can achieve.

FreddyLeaf · 2023-12-26T05:53:49Z

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: #76383. Comments are welcome there. For this PR, I added warnings to features only but not cpuname, mainly to reduce efforts. Especially when using -march=native on a knl machine, these warnings can also be emitted. Are you recommending removing features from the warning message?

FreddyLeaf · 2024-01-02T08:51:07Z

ping for review
@RKSimon are we aligned on the direction to removing knl/knm supports in the end?

RKSimon · 2024-01-02T16:41:53Z

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 names, but we shouldn't need to support the xeon phi specific ISAs.

We should keep asm handling for avx512er/avx512pf/etc but no need for attributes/intrinsics handling for them - if somebody needs to write assembly for them we shouldn't prevent it.

We should retain -march=native detection if we can, but not mandatory.

I also think we need a policy regarding what test coverage we need for various avx512 features (when should we assume avx512vl etc.)

Does that sound OK?

phoebewang · 2024-01-03T00:43:55Z

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.
I also imagine we can turn any avx512 feature, e.g., bool hasBWI() {return HasBWI;} into bool hasBWI() {return HasBWI & HasVLX;}, then remove all hasVLX checks in the code, e.g., Subtarget.hasVLX() && Subtarget.hasBWI() to Subtarget.hasBWI().

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.

This will require compiler and tests continue to handle cases avx512f/avx512cd without avx512vl. It conflicts with my expectation for hasVLX clean up. But maybe we can preserve these handling for few features for a short period.

We should keep asm handling for avx512er/avx512pf/etc but no need for attributes/intrinsics handling for them - if somebody needs to write assembly for them we shouldn't prevent it.

+1

FreddyLeaf · 2024-01-03T07:13:23Z

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 simplify large amounts of logic codes in backend, which is very beneficial.

RKSimon · 2024-01-03T11:53:21Z

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.

phoebewang · 2024-01-03T12:55:52Z

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.

RKSimon · 2024-01-03T14:42:01Z

Sorry, we'd require both avx512f and avx512cd to work without avx512vl - but everything afterward (avx512bw, avx512dq, ....) we could assume avx512vl is enabled.

FreddyLeaf · 2024-01-04T00:21:23Z

@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?

FreddyLeaf · 2024-01-04T13:06:34Z

@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?

That's correct - we keep -march/mtune/mcpu support for knl/knm but reduce its feature set to avx512f/avx512cd and we don't provide any support for xeon-phi specific features (avx512pf etc.) apart from the minimal binutils/assembly handling necessary.

If we keep support for VPOPCNTDQ on knm then yes we will need to allow non-VLX handling, but I don't know much about general availability of knm workstations (knl cpus/machines do turn up on ebay etc. quite frequently).

Thanks confirming! Modified the warning message and commit title.

FreddyLeaf · 2024-01-05T08:48:54Z

ping for review

clang/test/Driver/cl-x86-flags.c

clang/test/Misc/warning-flags.c

FreddyLeaf · 2024-01-08T07:05:33Z

ping for review.

clang/docs/ReleaseNotes.rst

phoebewang

LGTM.

RKSimon

LGTM - please make sure you adjust the commit message (the patch summary doesn't refer to removing just the knl/knm specific ISAs)

FreddyLeaf · 2024-01-09T11:42:58Z

Thank you all!

…SAs. (llvm#75580) Since Knight Landing and Knight Mill microarchitectures are EOL, we would like to remove intrinsic supports for its specific ISA in LLVM 19. In LLVM 18, we will first emit a warning for the usage.

Cont. patch after #75580

Clang 19 has removed support for the -mavx512pf and -mavx512er flags, for the Intel Xeon Phi (aka "Knights Landing"/knl or "Knights Mill"/knm) [1] [2]. This causes fatal errors during configuration of math/blis: Compiling obj/x86_64/kernels/knl/1m/bli_dpackm_knl_asm_24x8.o ('knl' CFLAGS for kernels) cc: fatal error: unknown argument '-mavx512pf'; did you mean '-mavx512f'? gmake: *** [Makefile:653: obj/x86_64/kernels/knl/1m/bli_dpackm_knl_asm_24x8.o] Error 1 Add an EXTRA_PATCHES entry to deal with this situation. Note that in the future, this may also have to be done for gcc 15 and later. In that case, the patch might be done unconditionally. [1] llvm/llvm-project#75580 [2] llvm/llvm-project#92883 PR: 280783 Approved by: maintainer timeout (2 weeks) MFH: 2024Q3

Clang 19 has removed support for the -mavx512pf and -mavx512er flags, for the Intel Xeon Phi (aka "Knights Landing"/knl or "Knights Mill"/knm) [1] [2]. This causes fatal errors during configuration of math/blis: Compiling obj/x86_64/kernels/knl/1m/bli_dpackm_knl_asm_24x8.o ('knl' CFLAGS for kernels) cc: fatal error: unknown argument '-mavx512pf'; did you mean '-mavx512f'? gmake: *** [Makefile:653: obj/x86_64/kernels/knl/1m/bli_dpackm_knl_asm_24x8.o] Error 1 Add an EXTRA_PATCHES entry to deal with this situation. Note that in the future, this may also have to be done for gcc 15 and later. In that case, the patch might be done unconditionally. [1] llvm/llvm-project#75580 [2] llvm/llvm-project#92883 PR: 280783 Approved by: maintainer timeout (2 weeks) MFH: 2024Q3 (cherry picked from commit 885ff9e)

Clang 19 has removed support for the -mavx512pf and -mavx512er flags, for the Intel Xeon Phi (aka "Knights Landing"/knl or "Knights Mill"/knm) [1] [2]. This causes fatal errors during configuration of math/blis: Compiling obj/x86_64/kernels/knl/1m/bli_dpackm_knl_asm_24x8.o ('knl' CFLAGS for kernels) cc: fatal error: unknown argument '-mavx512pf'; did you mean '-mavx512f'? gmake: *** [Makefile:653: obj/x86_64/kernels/knl/1m/bli_dpackm_knl_asm_24x8.o] Error 1 Add an EXTRA_PATCHES entry to deal with this situation. Note that in the future, this may also have to be done for gcc 15 and later. In that case, the patch might be done unconditionally. [1] llvm/llvm-project#75580 [2] llvm/llvm-project#92883 PR: 280783 Approved by: maintainer timeout (2 weeks) MFH: 2024Q3

[X86] Emit Warnings for frontend options to enable knl/knm.

e16afbd

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.

llvmbot added clang Clang issues not falling into any other category backend:X86 clang:driver 'clang' and 'clang++' user-facing binaries. Not 'clang-cl' clang:frontend Language frontend issues, e.g. anything involving "Sema" labels Dec 15, 2023

FreddyLeaf requested review from RKSimon, phoebewang and KanRobert December 15, 2023 09:42

add release note

fc7e6d3

topperc reviewed Dec 18, 2023

View reviewed changes

clang/include/clang/Basic/DiagnosticCommonKinds.td Outdated Show resolved Hide resolved

FreddyLeaf added 2 commits December 18, 2023 11:39

Address comments.

3eb6b00

Address comments cont.

6401cdf

Refine warning message.

2dcf1c3

FreddyLeaf changed the title ~~[X86] Emit Warnings for frontend options to enable knl/knm.~~ [X86] Emit Warnings for frontend options to enable knl/knm specific ISAs. Jan 4, 2024

phoebewang reviewed Jan 5, 2024

View reviewed changes

clang/test/Driver/cl-x86-flags.c Show resolved Hide resolved

phoebewang reviewed Jan 5, 2024

View reviewed changes

clang/test/Misc/warning-flags.c Outdated Show resolved Hide resolved

FreddyLeaf added 2 commits January 5, 2024 17:35

Address comments.

1d3f767

Merge branch 'main' into warning_phi

7a27172

RKSimon reviewed Jan 8, 2024

View reviewed changes

clang/docs/ReleaseNotes.rst Outdated Show resolved Hide resolved

FreddyLeaf added 2 commits January 9, 2024 09:50

address comment,

fef605e

indention

5c5325c

phoebewang reviewed Jan 9, 2024

View reviewed changes

clang/docs/ReleaseNotes.rst Show resolved Hide resolved

phoebewang approved these changes Jan 9, 2024

View reviewed changes

RKSimon approved these changes Jan 9, 2024

View reviewed changes

KanRobert approved these changes Jan 9, 2024

View reviewed changes

FreddyLeaf merged commit 19870ed into llvm:main Jan 9, 2024

FreddyLeaf deleted the warning_phi branch January 9, 2024 11:43

FreddyLeaf mentioned this pull request May 21, 2024

[X86] Remove knl/knm specific ISAs supports #92883

Merged

FreddyLeaf added a commit that referenced this pull request May 23, 2024

[X86] Remove knl/knm specific ISAs supports (#92883)

282d2ab

Cont. patch after #75580

dbabokin mentioned this pull request May 28, 2024

avx512knl-* targets EOL ispc/ispc#2867

Closed

[X86] Emit Warnings for frontend options to enable knl/knm specific ISAs. #75580

[X86] Emit Warnings for frontend options to enable knl/knm specific ISAs. #75580

Uh oh!

Conversation

FreddyLeaf commented Dec 15, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

llvmbot commented Dec 15, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

RKSimon commented Dec 15, 2023

Uh oh!

FreddyLeaf commented Dec 15, 2023

Uh oh!

FreddyLeaf commented Dec 15, 2023

Uh oh!

phoebewang commented Dec 15, 2023

Uh oh!

KanRobert commented Dec 18, 2023

Uh oh!

Uh oh!

RKSimon commented Dec 19, 2023

Uh oh!

phoebewang commented Dec 19, 2023

Uh oh!

FreddyLeaf commented Dec 26, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

FreddyLeaf commented Jan 2, 2024

Uh oh!

RKSimon commented Jan 2, 2024

Uh oh!

phoebewang commented Jan 3, 2024

Uh oh!

FreddyLeaf commented Jan 3, 2024

Uh oh!

RKSimon commented Jan 3, 2024

Uh oh!

phoebewang commented Jan 3, 2024

Uh oh!

RKSimon commented Jan 3, 2024

Uh oh!

FreddyLeaf commented Jan 4, 2024

Uh oh!

FreddyLeaf commented Jan 4, 2024

Uh oh!

FreddyLeaf commented Jan 5, 2024

Uh oh!

Uh oh!

Uh oh!

FreddyLeaf commented Jan 8, 2024

Uh oh!

Uh oh!

Uh oh!

phoebewang left a comment

Choose a reason for hiding this comment

Uh oh!

RKSimon left a comment

Choose a reason for hiding this comment

Uh oh!

FreddyLeaf commented Jan 9, 2024

Uh oh!

Uh oh!

FreddyLeaf commented Dec 15, 2023 •

edited

Loading

llvmbot commented Dec 15, 2023 •

edited

Loading

FreddyLeaf commented Dec 26, 2023 •

edited

Loading