RFC: [X86][Intel] Remove all-end supports of Intel knl/knm/mic_avx512 targets

Clang Frontend
, ,
1

Hi All,

I want to remove the supports based on reasons below:

  1. INTEL has officially announced these products’ EOL on about Aug. 2017

  2. 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.

  3. It sometimes leads to bad performance by wrong usage of options.

  4. We can claim this change on release notes to notify users intentionally support these targets to use older releases.

If you don’t have strong will against this proposal, I’ll work out a patch ASAP.

Comments are highly welcomed!

Thanks,

Freddy

2

IIRC, I used all three of them. If the hardware is not available and LLVM’s support is incomplete, it seems a good idea to remove the code. Rather than claiming support which is incomplete.

2 Likes
3

Tagging x86 code owners/interested parties @RKSimon @phoebe @topperc @nwg

4

Thanks @pogo59 I’m supportive for this RFC. IIRC, @RKSimon did some work for KNL, what’s your opinion?

5

It would be more polite to delay this until after the next (17.0) release this summer, and make it clear in the 17.0 release notes that support will be removed in the following release.

However, I’m always hesitant to remove support of a particular arch if we can avoid it, what in particular is causing a problem and could we not just fix/remove those issues? If we can reduce the maintenance burden to (near)-zero then its just yet another x86 arch.

6

It would be more polite to delay this until after the next (17.0) release this summer, and make it clear in the 17.0 release notes that support will be removed in the following release.

Strongly agree with this. Could be add a warning indicating that deprecation is likely imminent after 17?
Hopefully this would prompt anyone still using the targets to make a ticket so we can reevaluate.

However, I’m always hesitant to remove support of a particular arch if we can avoid it, what in particular is causing a problem and could we not just fix/remove those issues? If we can reduce the maintenance burden to (near)-zero then its just yet another x86 arch.

+1.

So far at least, it doesn’t seem like the maintenance burden of knm/knl is overwhelming enough to justify pulling the rug out from under the potential users.

Is there some motivating case for the costs that’s supporting this proposal?

7

Strong +1

Additionally, this is a breaking change, so it should follow our policy for communicating breaking changes to interested parties: LLVM Developer Policy — LLVM 17.0.0git documentation