<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 06/14/2017 10:08 AM, Sanjay Patel
wrote:<br>
</div>
<blockquote
cite="mid:CA+wODit49MegqLLvf4Zn68K=srsGhqZ_tPPo73Fj+G639BcF=w@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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 moz-do-not-send="true"
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>
</div>
</div>
</blockquote>
<br>
Sounds good. In that case, I agree.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CA+wODit49MegqLLvf4Zn68K=srsGhqZ_tPPo73Fj+G639BcF=w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>