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.
