spatel added subscribers: scanon, andrew.w.kaylor.
spatel added inline comments.
================
Comment at: lib/CodeGen/CGBuiltin.cpp:7932
break;
case X86::BI__builtin_ia32_cmppd256:
ID = Intrinsic::x86_avx_cmp_pd_256;
----------------
dtemirbulatov wrote:
> spatel wrote:
> > 1. Should we handle the 'pd256' version the same way?
> > 2. How about the 0xb ('false') constant? It should produce a zero here?
> > 3. Can or should we deal with the signalling versions (0x1b, 0x1f) too?
> >
> hm looks like 0xb(_CMP_FALSE_OQ) is ordered, so it is not possible and 0x1b
> or 0x1f might emit a signal.
I didn't follow this reasoning.
1. The 0xB compare predicate will return 'false' (all zeros) no matter what the
inputs are. "Ordered" in this definition is irrelevant; just like "unordered"
is irrelevant for predicate 0xF (TRUE_UQ).
It's probably helpful to run the program attached to PR28110 (
https://bugs.llvm.org/show_bug.cgi?id=28110 ) to confirm or deny if these
predicates behave like you expect.
2. Another possibly misleading wording: "non-signaling" does not actually mean
non-signaling for all values. It means "non-signaling for QNAN, but still
signaling for SNAN". Therefore, I think we're changing SNAN behavior by folding
*any* of these preds to constant values. We should've asked this first: is that
fold allowed in the default FPENV state that we assume that clang is operating
in? ( cc'ing @andrew.w.kaylor and @scanon for advice)
https://reviews.llvm.org/D33406
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
