https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71559
Ilya Enkovich <ienkovich at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ienkovich at gcc dot gnu.org --- Comment #5 from Ilya Enkovich <ienkovich at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #3) > I'd say it is a bug in ix86_fp_cmp_code_to_pcmp_immediate that it handles > only a small portion of the FP comparison codes, while VCMPP[SD] > instructions should be able to handle everything needed. > But, I'm also surprised where the values in that function come from. > Looking at the D modifier expansion in i386.c that is used for AVX vcmp, I > see that: > code %D3 emits corresponding imm > ix86_fp_cmp_code_to_pcmp_immediate > UNEQ eq_us 0x18 ICE > EQ eq 0 8 > UNLT nge 9 ICE > LT lt 1 0x19 > UNLE ngt 0xa ICE > LE le 2 0x1a > UNORDERED unord 3 ICE > LTGT neq_oq 0xc ICE > NE neq 4 4 > GE ge 0xd 0x15 > UNGE nlt 5 ICE > GT gt 0xe 0x16 > UNGT nle 6 ICE > ORDERED ord 7 ICE > So, there is agreement only on NE and nothing else. I took values for ix86_fp_cmp_code_to_pcmp_immediate from some table Kirill gave me and seems all values I used were unordered non-signaling variants. I don't fully understand the logic of imms in this table. Some of them are signalling and some of them are not. Also why is NE unordered? But I suspect there is good reason for such choice and suppose AVX512 compares should be put in a consistent state with AVX ones by fixing ix86_fp_cmp_code_to_pcmp_immediate appropriately.