[Bug d/98607] GDC merging computations but rounding mode has changed

2021-01-08 Thread ibuclaw at gdcproject dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98607

--- Comment #1 from Iain Buclaw  ---
To be fair, C++ does the same as well.  The problem is the inliner (though no
inlining occurs when using immintrin.h)

[Bug d/98607] GDC merging computations but rounding mode has changed

2021-01-09 Thread guillaume.piolat at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98607

--- Comment #2 from Guillaume Piolat  ---
It seems it is the same as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55752 ?

[Bug d/98607] GDC merging computations but rounding mode has changed

2021-01-09 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98607

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
The problem isn't inlining, but the fact that the rounding mode isn't modeled
in the IL, with dependencies between changing of that (or function calls that
could have changed it) and all the floating point arithmetic operations that
can be affected by that.
So, one needs to use explicit optimization barriers (inline asm, separate
functions with disabled inlining, etc.).

[Bug d/98607] GDC merging computations but rounding mode has changed

2021-01-09 Thread guillaume.piolat at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98607

--- Comment #4 from Guillaume Piolat  ---
So, I need to disable inlining for _mm_setcsr and that will be enough?

[Bug d/98607] GDC merging computations but rounding mode has changed

2021-01-09 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98607

--- Comment #5 from Jakub Jelinek  ---
No.  You need to put the code that is done with different rounding modes into
separate functions (and ensure those functions aren't inlined into their
caller).

[Bug d/98607] GDC merging computations but rounding mode has changed

2021-01-09 Thread guillaume.piolat at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98607

--- Comment #6 from Guillaume Piolat  ---
I provide intel intrinsics API for D, these intrinsics (like in C++) allows to
change the rounding mode, and about 200 other functions that depend on the
rounding mode can be called. I'm not the one in control of who calls what.

I don't see a workaround for C++ headers at
https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/gcc/config/i386/xmmintrin.h#L872

[Bug d/98607] GDC merging computations but rounding mode has changed

2021-01-09 Thread guillaume.piolat at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98607

--- Comment #7 from Guillaume Piolat  ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47617
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678

[Bug d/98607] GDC merging computations but rounding mode has changed

2021-01-09 Thread ibuclaw at gdcproject dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98607

--- Comment #8 from Iain Buclaw  ---
(In reply to Guillaume Piolat from comment #6)
> I provide intel intrinsics API for D, these intrinsics (like in C++) allows
> to change the rounding mode, and about 200 other functions that depend on
> the rounding mode can be called. I'm not the one in control of who calls
> what.
> 
> I don't see a workaround for C++ headers at
> https://github.com/gcc-mirror/gcc/blob/
> 16e2427f50c208dfe07d07f18009969502c25dc8/gcc/config/i386/xmmintrin.h#L872

Ah, I was mistaken last night.  Probably my quick conversion was wrong in some
way that prevented inlining.  On a second look, you'll find nothing in
xmmintrin.h that'll help you.

---
#include 
int main()
{
unsigned savedRounding = _MM_GET_ROUNDING_MODE();

_MM_SET_ROUNDING_MODE(_MM_ROUND_NEAREST);
union {
__m128i vec;
int array[4];
} A;
A.vec = _mm_cvtps_epi32(_mm_setr_ps(1.4f, -2.1f, 53.5f, -2.9f));
assert(A.array[0] == 1);
assert(A.array[1] == -2);
assert(A.array[2] == 54);
assert(A.array[3] == -3);

// GCC might merge this branch with above! Despite _MM_SET_ROUNDING_MODE 
// not being pure.
_MM_SET_ROUNDING_MODE(_MM_ROUND_DOWN);
A.vec = _mm_cvtps_epi32(_mm_setr_ps(1.4f, -2.1f, 53.5f, -2.9f));
assert(A.array[0] == 1);
assert(A.array[1] == -3);  // fails
assert(A.array[2] == 53);
assert(A.array[3] == -3);
return 0;
}
---

One workaround for the intel-intrinsics D library might be to insert a barrier
in _MM_SET_ROUNDING_MODE.

---
void _MM_SET_ROUNDING_MODE(int _MM_ROUND_)
{
asm { "" : : : "memory"; }
_mm_setcsr((_mm_getcsr() & ~_MM_ROUND_MASK) | _MM_ROUND_);
}

---

[Bug d/98607] GDC merging computations but rounding mode has changed

2021-01-15 Thread glisse at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98607

--- Comment #9 from Marc Glisse  ---
Since I doubt gdc handles rounding modes correctly for scalars, I think you can
ignore this issue in the implementation of the vector intrinsics for now (same
as we do in C and C++).

Note that gcc isn't alone here, llvm doesn't implement pragma fenv_access
either, and even visual studio, which does implement it for scalars, fails for
vectors. I did not test with Intel's compiler.