<div dir="ltr"><div><div><div>Let's make sure we're looking at the same example. The x86 instruction that I think we're discussing is cmpps/cmppd with constant predicate TRUE_UQ (0xF), FALSE_OQ (0xB), etc.<br><br></div>The expected output for cases including NaN inputs is shown by the program in PR28110:<br><a href="https://bugs.llvm.org/show_bug.cgi?id=28110">https://bugs.llvm.org/show_bug.cgi?id=28110</a><br><br></div>Based on the Intel documentation and the experimental data, the output value (ignoring exceptions) is never affected by the input value. It doesn't matter if we have NaN input, we should still produce a constant with -1 elements, so I don't think we need any relaxed-mode FP flags for this transform.<br><br></div>Here's a simpler test program:<br><br>#include <immintrin.h><br>#include <math.h><br>#include <stdio.h><br>#include <string.h><br><br>__m128 get_all_ones(__m128 a, __m128 b) {<br>  return _mm_cmp_ps(a, b, 15);<br>}<br><br>int main() {<br>  int elts[4];<br><br>  __m128 nan = (__m128) _mm_set1_ps(nanf(""));<br>  memcpy(elts, &nan, 16);<br>  printf("4 nans as hex: %x %x %x %x\n", elts[0], elts[1], elts[2], elts[3]);<br><br>  // The params to cmpps with pred #15 should not matter - it always returns all ones.<br>  // In this case one param is a nan.<br>  __m128 ones = get_all_ones(nan, _mm_set1_ps(42.0));<br>  memcpy(elts, &ones, 16);<br>  printf("expecting 4 all ones: %x %x %x %x\n", elts[0], elts[1], elts[2], elts[3]);<br><br>  // The params to cmpps with pred #15 should not matter - it always returns all ones.<br>  // In this case both params are nan.<br>  __m128 more_ones = get_all_ones(nan, nan);<br>  memcpy(elts, &more_ones, 16);<br>  printf("expecting 4 all ones: %x %x %x %x\n", elts[0], elts[1], elts[2], elts[3]);<br>  return 0;<br>}<br><div><div><br>$ clang cmptrue.c -mavx -O1<br>$ ./a.out<br>4 nans as hex: 7fc00000 7fc00000 7fc00000 7fc00000<br>expecting 4 all ones: ffffffff ffffffff ffffffff ffffffff<br>expecting 4 all ones: ffffffff ffffffff ffffffff ffffffff<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 14, 2017 at 7:34 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, Dinar,<br>
<br>
You should assume that FPU exceptions are not enabled. LLVM does not (currently) support them. That having been said, in this particular case, the output is also different if a NaN is produced (i.e. it produces a NaN and not a -1), and so I'd think you can only do this transformations when the call has the nnan flag (e.g. because the code was compiled with -ffinite-math-only).<br>
<br>
 -Hal<div class="HOEnZb"><div class="h5"><br>
<br>
On 06/14/2017 05:06 AM, Dinar Temirbulatov wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
We are interesting in expanding some vector operations directly in the<br>
IR form as constants <a href="https://reviews.llvm.org/D33406" rel="noreferrer" target="_blank">https://reviews.llvm.org/D3340<wbr>6</a>,<br>
for example: _mm256_cmp_ps("any input", "any input", _CMP_TRUE_UQ)<br>
should produce -1, -1, -1, ... vector, but for some values for example<br>
"1.00 -nan" if FPU exceptions were enabled this operation triggers the<br>
exception. Here is the question: Should we assume that FPENV was<br>
initialized with FE_ALL_EXCEPT by default or we could rely for example<br>
on "-fno-trapping-math" flag or we could completely ignore the FPU<br>
exception issue(see <a href="https://bugs.llvm.org/show_bug.cgi?id=6050" rel="noreferrer" target="_blank">https://bugs.llvm.org/show_bug<wbr>.cgi?id=6050</a>)?<br>
<br>
                 Thanks, Dinar.<br>
</blockquote>
<br></div></div><span class="HOEnZb"><font color="#888888">
-- <br>
Hal Finkel<br>
Lead, Compiler Technology and Programming Languages<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
<br>
</font></span></blockquote></div><br></div></div>