public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug rtl-optimization/108318] New: Floating point calculation moved out of loop despite fesetround
@ 2023-01-06 14:56 tkoenig at gcc dot gnu.org
2023-01-06 16:18 ` [Bug rtl-optimization/108318] " amonakov at gcc dot gnu.org
2023-01-06 17:29 ` pinskia at gcc dot gnu.org
0 siblings, 2 replies; 3+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2023-01-06 14:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108318
Bug ID: 108318
Summary: Floating point calculation moved out of loop despite
fesetround
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
#include <fenv.h>
void
foo (double res[4], double a, double b)
{
static const int rm[4]
= { FE_DOWNWARD, FE_TONEAREST, FE_TOWARDZERO, FE_UPWARD };
for (int i = 0; i < 4; ++i)
{
fesetround (rm[i]);
res[i] = a + b;
}
fesetround (FE_TONEAREST); // restore default
}
when compiled with recent trunk and -O3, yields
addsd %xmm1, %xmm0
pushq %r14
.cfi_def_cfa_offset 16
.cfi_offset 14, -16
pushq %rbp
.cfi_def_cfa_offset 24
.cfi_offset 6, -24
movq %rdi, %rbp
pushq %rbx
.cfi_def_cfa_offset 32
.cfi_offset 3, -32
xorl %ebx, %ebx
movq %xmm0, %r14
.L2:
movl rm.0(,%rbx,4), %edi
call fesetround
movq %r14, 0(%rbp,%rbx,8)
addq $1, %rbx
cmpq $4, %rbx
jne .L2
popq %rbx
.cfi_def_cfa_offset 24
xorl %edi, %edi
popq %rbp
.cfi_def_cfa_offset 16
popq %r14
.cfi_def_cfa_offset 8
jmp fesetround
.cfi_endproc
Seems all right after tree optimization, the *.optimized dump looks OK:
<bb 3> [local count: 858993457]:
# ivtmp.5_16 = PHI <ivtmp.5_7(3), 0(2)>
_1 = MEM[(int *)&rm + ivtmp.5_16 * 4];
fesetround (_1);
_5 = a_12(D) + b_13(D);
MEM[(double *)res_11(D) + ivtmp.5_16 * 8] = _5;
ivtmp.5_7 = ivtmp.5_16 + 1;
if (ivtmp.5_7 != 4)
goto <bb 3>; [80.00%]
else
goto <bb 4>; [20.00%]
<bb 4> [local count: 214748368]:
fesetround (0); [tail call]
return;
This does not seem to be a recent regression, this goes back to at
least gcc 4.1.2.
Noted by Michael S on comp.arch, on
https://groups.google.com/g/comp.arch/c/Izheu-k00Nw/m/oljg70SBBwAJ .
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug rtl-optimization/108318] Floating point calculation moved out of loop despite fesetround
2023-01-06 14:56 [Bug rtl-optimization/108318] New: Floating point calculation moved out of loop despite fesetround tkoenig at gcc dot gnu.org
@ 2023-01-06 16:18 ` amonakov at gcc dot gnu.org
2023-01-06 17:29 ` pinskia at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: amonakov at gcc dot gnu.org @ 2023-01-06 16:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108318
Alexander Monakov <amonakov at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amonakov at gcc dot gnu.org
--- Comment #1 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
Please see documentation for the -frounding-math option, but even with that
option added, your testcase still has the faux-invariant moved by RTL PRE
(-fno-gcse).
Interestingly, if your testcase is modified to compute the sum before the call:
#include <fenv.h>
void
foo (double res[4], double a, double b, double x[])
{
a = x[0];
b = x[1];
static const int rm[4]
= { FE_DOWNWARD, FE_TONEAREST, FE_TOWARDZERO, FE_UPWARD };
for (int i = 0; i < 4; ++i)
{
double t = a + b;
fesetround (rm[i]);
res[i] = t;
}
fesetround (FE_TONEAREST); // restore default
}
Then it demonstrates how a few *other* optimizations also perform unwanted
motion:
* SSA PRE (-fno-tree-pre)
* TER (-fno-tree-ter)
* RTL LIM (-fno-move-loop-invariants)
* and finally the register allocator (unavoidable)
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug rtl-optimization/108318] Floating point calculation moved out of loop despite fesetround
2023-01-06 14:56 [Bug rtl-optimization/108318] New: Floating point calculation moved out of loop despite fesetround tkoenig at gcc dot gnu.org
2023-01-06 16:18 ` [Bug rtl-optimization/108318] " amonakov at gcc dot gnu.org
@ 2023-01-06 17:29 ` pinskia at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-01-06 17:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108318
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Dup of bug 34678.
Techincally you need to use "#pragma STDC FENV_ACCESS ON" also to get this
correct but GCC does not implement that pragma which is what PR 34678 is about.
*** This bug has been marked as a duplicate of bug 34678 ***
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-01-06 17:29 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-06 14:56 [Bug rtl-optimization/108318] New: Floating point calculation moved out of loop despite fesetround tkoenig at gcc dot gnu.org
2023-01-06 16:18 ` [Bug rtl-optimization/108318] " amonakov at gcc dot gnu.org
2023-01-06 17:29 ` pinskia at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).