Smith, Kevin B via llvm-dev
2021-Jul-12 21:46 UTC
[llvm-dev] [RFC] Should -ffast-math affect intrinsics?
Sorry, missed a NOT or two.
This is what I meant to say:
It seems to me that the fast-math flags really should NOT affect intrinsics
implementations themselves, and that the fast-math flags should NOT allow
reassociation across the intrinsic calls. So, is this expected behavior, or just
something that no-one has noticed before?
It surprised me.4
I have also checked GCC behavior, which is consistent with clang, or vice versa.
Intel C/C++ compiler does not have fast math flags affect intrinsics, at least
it doesn't allow reassociation across the call boundaries and I haven't
checked the Microsoft compiler yet.
Kevin Smith
-----Original Message-----
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Smith,
Kevin B via llvm-dev
Sent: Monday, July 12, 2021 2:28 PM
To: llvm-dev at lists.llvm.org
Subject: [llvm-dev] [RFC] Should -ffast-math affect intrinsics?
I've got the following little program that illustrates what I think is a
problem. This is for X86/Intel64 intrinsics.
If compiled using
$ clang -O2 intrin_prob.c
$ a.out
2.000000, 3.000000
This is the expected result. But if compiled using $ clang -O2 -ffast-math
intrin_prob.c $ a.out 1.500000, 3.255000
This gets incorrect results, because reassociation happens across the calls to
the _mm_add_pd, and _mm_sub_pd intrinsics and the value that should have been
added and subtracted gets constant folded to zero. It seems to me that the
fast-math flags really should not affect intrinsics implementations themselves,
and that the fast-math flags should allow reassociation across the intrinsic
calls. So, is this expected behavior, or just something that no-one has noticed
before? It surprised me.
I have also checked GCC behavior, which is consistent with clang, or vice versa.
Intel C/C++ compiler does not have fast math flags affect intrinsics, at least
not for reassociation across the call boundaries and I haven't checked the
Microsoft compiler yet.
An easy "fix" would be to add
#pragma float_control(precise, on)
or
#pragma clang fp reassociate(off)
near the top of immintrin.h to cause all intrinsics to ignore all fast-math
flags, or at least ignore reassociation.
$ cat intrin_prob.c
#include <immintrin.h>
#include <stdio.h>
static union {
double u1[2];
__m128d u2;
} t1[1] = {1.25, 3.25};
int main(int argc, char **argv) {
__m128d t2;
__m128d t3;
// This is just so the compiler cannot constant fold
// and know the values of t1.
t1[0].u1[0] += argc * 0.25;
t1[0].u1[1] += argc * .005;
// This value when added, then subtracted should cause
// the values to be truncated to integer. If the compiler
// optimizes the add and subtract out by doing
// reassociation, then the printed values will have
// fractional parts. If the compiler does the intrinsics
// as expected, then the values printed will have no fractional part.
t2 = _mm_castsi128_pd(_mm_set_epi32((int)((0x4338000000000000uLL) >>
32),
(int)((0x4338000000000000uLL) >> 0),
(int)((0x4338000000000000uLL) >>
32),
(int)((0x4338000000000000uLL) >>
0)));
t3 = _mm_add_pd(t1[0].u2, t2);
t3 = _mm_sub_pd(t3, t2);
t1[0].u2 = t3;
printf("%f, %f\n", t1[0].u1[0], t1[0].u1[1]);
return 0;
}
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Wang, Pengfei via llvm-dev
2021-Jul-14 09:24 UTC
[llvm-dev] [RFC] Should -ffast-math affect intrinsics?
Hi Kevin,
AFAIK, it is expected behavior that the fast-math flags affect llvm intrinsics.
An example is llvm.vector.reduce.fadd.*
https://llvm.org/docs/LangRef.html#llvm-vector-reduce-fadd-intrinsic.
But how fast-math flags affect target dependent intrinsics is a bit vague.
Because target intrinsics are expressions of the inherent characteristic of
native instructions. So they imply the special FP model sometimes. E.g.: on X86,
we have some intrinsics that assume to be used under fp-model=strict, e.g.
_mm512_add_round_ps etc., while some assume to be used with given constraint
(similar to fast math flags), e.g. _mm_max_ps etc.
In general, I think we should respect fast math flags on target intrinsics too.
We don't do much of it simply because we don't put the emphasis on the
performance of target intrinsics. There was an optimization under fast math flag
in X86InstCombineIntrinsic.cpp, which I removed in D85385 for other propose.
Thanks
Pengfei
-----Original Message-----
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Smith,
Kevin B via llvm-dev
Sent: Tuesday, July 13, 2021 5:46 AM
To: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] [RFC] Should -ffast-math affect intrinsics?
Sorry, missed a NOT or two.
This is what I meant to say:
It seems to me that the fast-math flags really should NOT affect intrinsics
implementations themselves, and that the fast-math flags should NOT allow
reassociation across the intrinsic calls. So, is this expected behavior, or just
something that no-one has noticed before?
It surprised me.4
I have also checked GCC behavior, which is consistent with clang, or vice versa.
Intel C/C++ compiler does not have fast math flags affect intrinsics, at least
it doesn't allow reassociation across the call boundaries and I haven't
checked the Microsoft compiler yet.
Kevin Smith
-----Original Message-----
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Smith,
Kevin B via llvm-dev
Sent: Monday, July 12, 2021 2:28 PM
To: llvm-dev at lists.llvm.org
Subject: [llvm-dev] [RFC] Should -ffast-math affect intrinsics?
I've got the following little program that illustrates what I think is a
problem. This is for X86/Intel64 intrinsics.
If compiled using
$ clang -O2 intrin_prob.c
$ a.out
2.000000, 3.000000
This is the expected result. But if compiled using $ clang -O2 -ffast-math
intrin_prob.c $ a.out 1.500000, 3.255000
This gets incorrect results, because reassociation happens across the calls to
the _mm_add_pd, and _mm_sub_pd intrinsics and the value that should have been
added and subtracted gets constant folded to zero. It seems to me that the
fast-math flags really should not affect intrinsics implementations themselves,
and that the fast-math flags should allow reassociation across the intrinsic
calls. So, is this expected behavior, or just something that no-one has noticed
before? It surprised me.
I have also checked GCC behavior, which is consistent with clang, or vice versa.
Intel C/C++ compiler does not have fast math flags affect intrinsics, at least
not for reassociation across the call boundaries and I haven't checked the
Microsoft compiler yet.
An easy "fix" would be to add
#pragma float_control(precise, on)
or
#pragma clang fp reassociate(off)
near the top of immintrin.h to cause all intrinsics to ignore all fast-math
flags, or at least ignore reassociation.
$ cat intrin_prob.c
#include <immintrin.h>
#include <stdio.h>
static union {
double u1[2];
__m128d u2;
} t1[1] = {1.25, 3.25};
int main(int argc, char **argv) {
__m128d t2;
__m128d t3;
// This is just so the compiler cannot constant fold
// and know the values of t1.
t1[0].u1[0] += argc * 0.25;
t1[0].u1[1] += argc * .005;
// This value when added, then subtracted should cause
// the values to be truncated to integer. If the compiler
// optimizes the add and subtract out by doing
// reassociation, then the printed values will have
// fractional parts. If the compiler does the intrinsics
// as expected, then the values printed will have no fractional part.
t2 = _mm_castsi128_pd(_mm_set_epi32((int)((0x4338000000000000uLL) >>
32),
(int)((0x4338000000000000uLL) >> 0),
(int)((0x4338000000000000uLL) >>
32),
(int)((0x4338000000000000uLL) >>
0)));
t3 = _mm_add_pd(t1[0].u2, t2);
t3 = _mm_sub_pd(t3, t2);
t1[0].u2 = t3;
printf("%f, %f\n", t1[0].u1[0], t1[0].u1[1]);
return 0;
}
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev