https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71559
--- Comment #6 from Carlos Tripiana Montes <tripiana at gmail dot com> --- Hope you guys can do that and fix this problem soon. It would much appreciated as we are (at Barcelona Supercomputing Center, Spain) doing research on KNL and we need the fastest/most robust code we can obtain. Thanks in advance. (In reply to Ilya Enkovich from comment #5) > (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.
