Hi Jakub, Sorry for the late response since I am on vacation for now.
> As the following testcase shows, the above change was incorrect. > > Using aes isa for the second alternative is obviously wrong, aes is enabled > whenever -maes is, regardless of -mavx or -mno-avx, so the above change > means that for -maes -mno-avx RA can choose, either it matches the first > alternative with the dup operand, or it matches the second one (but that > is of course wrong because vaesenc VEX encoded insn needs AES & AVX CPUID). When I wrote that patch, I suppose it will never match the second one when AVX is not enabled because it will immediately drop to the first one so the second one is automatically AES && AVX, which is tricky here. But this patch is buggy when "-maes -mavx512vl -mno-vaes" with %xmm16+ so your change is needed, really appreciate that. > > The big question is if "Since VAES should not imply AES" is the case or not. > Looking around at what LLVM does on godbolt, seems since clang 6 which added > -mvaes support -mvaes there implies -maes, but GCC treats those two > independent. > > Now, if we'd take the LLVM path of making -mvaes imply -maes and -mno-aes > imply -mno-vaes, then we should probably just revert the above patch and > tweak common/config/i386/ to do the implications (+ add the testcase from > this patch). LLVM always had less restrictions on ISA under such circumstances, I would like to stick to how SDM did when implementing that, which is a little conservative. However, I am also ok with VAES implying AES if there is no real HW that has VAES w/o AES to reduce complexity in this scenario. Thx, Haochen
