Rewrite to use a "cx8" feature flag that is set for all i586 and greater CPUs as well as generic. This assumes generic is never passed in a run of clang through the driver. And anyone using -cc1 directly is unlikely to be using an i486.

Rebase after precommit of NFC change. Add llc tests for existing PRs.

In D59567#1436035, @RKSimon wrote:

IIRC we don't use libcalls for popcnt - we just expand

Update doxygen comments

In D59576#1437153, @efriedma wrote:

Does this affect the assembler? If so, should we also have an assembler testcase?

Remove commented out code

Patch here https://reviews.llvm.org/D59566

LGTM

In D28213#1435542, @efriedma wrote:

It's kind of awkward to use ">=" on a CPU enum, but yes, that's the right idea.

It's still wrong. I think this might fix it?

Add optsize qualification. Copied one of the test cases in avx512-mask-op.ll and add the optsize attribute to test.

Add the test file that I forgot to git add before running arcanist

Shouldn't the definition in BuiltinsWebAssembly.def be updated to include an 'I' in the type string so that this will be properly diagnosed in the frontend?

Switch back to using endswith

Extend to cover VPCMP as well. Use TSFlags to make some of the printing decisions rather than switching on the enum. I think this should be better than the jump tables that switching on the enum would require.

Add comments based on rnk's review

LGTM

LGTM

Fix bad comment copy/paste

Add the test file

I forgot about another issue I know about. Currently the EVEX form of instruction like "vcvtss2si (%rax), %ebx" are removed from the assembly matcher table. Since none of the operands are xmm/ymm/zmm registers when the source is memory there was never a reason to use EVEX. And the sorting criteria in the AsmMatcherTable can't order it correctly to put VEX first since the operands are identical. Normally the fact that VR128 is a subclass of VR128X is what give VEX preference over EVEX in the table. But that doesn't apply here so they get sorted by the enum value from X86GenInstrInfo.inc which puts EVEX first.

In D59266#1428241, @RKSimon wrote:

Might need to skip use of the _REV MOV instructions for this too, but I haven't done that yet.

Can you elaborate?

I think the only error we have for X86 is trying to use a -march for a cpu that only supports 32 bit but compiling 64 bit code.

Is this ok with the backend fixed? Or do you want me factor this into HasCX16 which I think is only used by the defineMacro and the return for hasFeature("cx16")? And I think hasFeature("cx16") is only used by that getMaxAtomicWidth() code which is only called on 64 bit.

Most if not all of the test cases in test/CodeGen/X86/atomic128.ll fail with a fatal error if you run it in 32-bit mode with -mattr=+cx16 Looks like the backend is also bad at checking 64 bit mode.

Isn’t that setMaxAtomicWidth in the x86-64 derived class?