- User Since
- Jul 30 2013, 7:58 PM (294 w, 1 d)
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.
Update doxygen comments
Remove commented out code
Tue, Mar 19
Patch here https://reviews.llvm.org/D59566
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
Mon, Mar 18
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?
Sun, Mar 17
Switch back to using endswith
Sat, Mar 16
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.
Fri, Mar 15
Add comments based on rnk's review
Thu, Mar 14
Wed, Mar 13
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.
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?