public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/106078] New: Invalid loop invariant motion with non-call-exceptions
@ 2022-06-24 11:21 hubicka at gcc dot gnu.org
2022-06-24 11:40 ` [Bug middle-end/106078] " hubicka at gcc dot gnu.org
` (6 more replies)
0 siblings, 7 replies; 9+ messages in thread
From: hubicka at gcc dot gnu.org @ 2022-06-24 11:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106078
Bug ID: 106078
Summary: Invalid loop invariant motion with non-call-exceptions
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
Here I think it is invalid to move *b out of the loop with
-fnon-call-exceptions:
int array[10000];
int test(short *b,int e, int f)
{
for (int i = 0; i<10000;i++)
{
e/=f;
array[i]+=*b+e;
}
}
jan@localhost:~> more t.s
.text
.file "t.c"
.globl _Z4testPsii # -- Begin function _Z4testPsii
.p2align 4, 0x90
.type _Z4testPsii,@function
_Z4testPsii: # @_Z4testPsii
.cfi_startproc
# %bb.0:
movl %edx, %ecx
movl %esi, %eax
movswl (%rdi), %esi
xorl %edi, %edi
.p2align 4, 0x90
.LBB0_1: # =>This Inner Loop Header: Depth=1
cltd
idivl %ecx
movl %eax, %edx
addl %esi, %edx
addl %edx, array(,%rdi,4)
addq $1, %rdi
jmp .LBB0_1
.Lfunc_end0:
compiled code will segfault instead dividing by zero.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/106078] Invalid loop invariant motion with non-call-exceptions
2022-06-24 11:21 [Bug middle-end/106078] New: Invalid loop invariant motion with non-call-exceptions hubicka at gcc dot gnu.org
@ 2022-06-24 11:40 ` hubicka at gcc dot gnu.org
2022-06-24 12:58 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
6 siblings, 0 replies; 9+ messages in thread
From: hubicka at gcc dot gnu.org @ 2022-06-24 11:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106078
--- Comment #1 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
This is version that does not need -fnon-call-exceptions
If called test (NULL, 0) it should be indefinitely increasing val rather then
segfaulting. Seems clang gets this one right.
int array[10000];
volatile int val;
int test(short *b,int s)
{
for (int i = 0; i<10000;i++)
{
for (int j = 0; j < 10; j+=s)
val++;
array[i]+=*b;
}
}
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/106078] Invalid loop invariant motion with non-call-exceptions
2022-06-24 11:21 [Bug middle-end/106078] New: Invalid loop invariant motion with non-call-exceptions hubicka at gcc dot gnu.org
2022-06-24 11:40 ` [Bug middle-end/106078] " hubicka at gcc dot gnu.org
@ 2022-06-24 12:58 ` rguenth at gcc dot gnu.org
2022-06-24 13:00 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
6 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-06-24 12:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106078
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2022-06-24
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #1)
> This is version that does not need -fnon-call-exceptions
> If called test (NULL, 0) it should be indefinitely increasing val rather
> then segfaulting. Seems clang gets this one right.
>
> int array[10000];
> volatile int val;
> int test(short *b,int s)
> {
> for (int i = 0; i<10000;i++)
> {
> for (int j = 0; j < 10; j+=s)
> val++;
> array[i]+=*b;
> }
> }
For this one it's PRE hoisting *b across the endless loop (PRE handles
calls as possibly not returning but not loops as possibly not terminating...)
So it's a different bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/106078] Invalid loop invariant motion with non-call-exceptions
2022-06-24 11:21 [Bug middle-end/106078] New: Invalid loop invariant motion with non-call-exceptions hubicka at gcc dot gnu.org
2022-06-24 11:40 ` [Bug middle-end/106078] " hubicka at gcc dot gnu.org
2022-06-24 12:58 ` rguenth at gcc dot gnu.org
@ 2022-06-24 13:00 ` rguenth at gcc dot gnu.org
2022-06-24 13:01 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-06-24 13:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106078
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
Keywords| |wrong-code
Status|NEW |ASSIGNED
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #0)
> Here I think it is invalid to move *b out of the loop with
> -fnon-call-exceptions:
>
> int array[10000];
> int test(short *b,int e, int f)
> {
> for (int i = 0; i<10000;i++)
> {
> e/=f;
> array[i]+=*b+e;
> }
> }
LIM uses nonpure_call_p to see whether a stmt possibly terminates a block
(and 'contains_call'). We probably have to treat const/pure throwing
calls and general throwing (or trapping) stmts the same way.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/106078] Invalid loop invariant motion with non-call-exceptions
2022-06-24 11:21 [Bug middle-end/106078] New: Invalid loop invariant motion with non-call-exceptions hubicka at gcc dot gnu.org
` (2 preceding siblings ...)
2022-06-24 13:00 ` rguenth at gcc dot gnu.org
@ 2022-06-24 13:01 ` rguenth at gcc dot gnu.org
2022-06-25 13:33 ` Jan Hubicka
2022-06-25 13:33 ` hubicka at kam dot mff.cuni.cz
` (2 subsequent siblings)
6 siblings, 1 reply; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-06-24 13:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106078
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> (In reply to Jan Hubicka from comment #1)
> > This is version that does not need -fnon-call-exceptions
> > If called test (NULL, 0) it should be indefinitely increasing val rather
> > then segfaulting. Seems clang gets this one right.
> >
> > int array[10000];
> > volatile int val;
> > int test(short *b,int s)
> > {
> > for (int i = 0; i<10000;i++)
> > {
> > for (int j = 0; j < 10; j+=s)
> > val++;
> > array[i]+=*b;
> > }
> > }
>
> For this one it's PRE hoisting *b across the endless loop (PRE handles
> calls as possibly not returning but not loops as possibly not terminating...)
> So it's a different bug.
Btw, C++ requiring forward progress makes the testcase undefined.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bug middle-end/106078] Invalid loop invariant motion with non-call-exceptions
2022-06-24 13:01 ` rguenth at gcc dot gnu.org
@ 2022-06-25 13:33 ` Jan Hubicka
0 siblings, 0 replies; 9+ messages in thread
From: Jan Hubicka @ 2022-06-25 13:33 UTC (permalink / raw)
To: rguenth at gcc dot gnu.org; +Cc: gcc-bugs
> > For this one it's PRE hoisting *b across the endless loop (PRE handles
> > calls as possibly not returning but not loops as possibly not terminating...)
> > So it's a different bug.
>
> Btw, C++ requiring forward progress makes the testcase undefined.
In my understanding access to volatile variable is a forward progres:
In a valid C++ program, every thread eventually does one of the
following:
-terminate
-makes a call to an I/O library function
-performs an access through a volatile glvalue
-performs an atomic operation or a synchronization operation
I think one can also replace volatile access by atomics: we only need to
know the side effects of that operation.
Honza
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/106078] Invalid loop invariant motion with non-call-exceptions
2022-06-24 11:21 [Bug middle-end/106078] New: Invalid loop invariant motion with non-call-exceptions hubicka at gcc dot gnu.org
` (3 preceding siblings ...)
2022-06-24 13:01 ` rguenth at gcc dot gnu.org
@ 2022-06-25 13:33 ` hubicka at kam dot mff.cuni.cz
2022-07-22 10:24 ` [Bug rtl-optimization/106078] RTL PRE " rguenth at gcc dot gnu.org
2022-07-22 10:27 ` rguenth at gcc dot gnu.org
6 siblings, 0 replies; 9+ messages in thread
From: hubicka at kam dot mff.cuni.cz @ 2022-06-25 13:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106078
--- Comment #5 from hubicka at kam dot mff.cuni.cz ---
> > For this one it's PRE hoisting *b across the endless loop (PRE handles
> > calls as possibly not returning but not loops as possibly not terminating...)
> > So it's a different bug.
>
> Btw, C++ requiring forward progress makes the testcase undefined.
In my understanding access to volatile variable is a forward progres:
In a valid C++ program, every thread eventually does one of the
following:
-terminate
-makes a call to an I/O library function
-performs an access through a volatile glvalue
-performs an atomic operation or a synchronization operation
I think one can also replace volatile access by atomics: we only need to
know the side effects of that operation.
Honza
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug rtl-optimization/106078] RTL PRE with non-call-exceptions
2022-06-24 11:21 [Bug middle-end/106078] New: Invalid loop invariant motion with non-call-exceptions hubicka at gcc dot gnu.org
` (4 preceding siblings ...)
2022-06-25 13:33 ` hubicka at kam dot mff.cuni.cz
@ 2022-07-22 10:24 ` rguenth at gcc dot gnu.org
2022-07-22 10:27 ` rguenth at gcc dot gnu.org
6 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-07-22 10:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106078
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Invalid loop invariant |RTL PRE with
|motion with |non-call-exceptions
|non-call-exceptions |
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org
Component|middle-end |rtl-optimization
Status|ASSIGNED |NEW
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note it is RTL PRE hoisting the load from b, not invariant motion. On the
testcase w/o -fnon-call-exceptions it's tree PRE (or if disabled, RTL PRE
again)
doing the hoisting.
For some reason for the non-call-exception PRE case the following does not
help.
diff --git a/gcc/gcse-common.cc b/gcc/gcse-common.cc
index e86d4c4f477..16f804d13f9 100644
--- a/gcc/gcse-common.cc
+++ b/gcc/gcse-common.cc
@@ -82,7 +82,8 @@ record_last_mem_set_info_common (rtx_insn *insn,
modify_mem_list[bb].safe_push (insn);
bitmap_set_bit (modify_mem_list_set, bb);
- if (CALL_P (insn))
+ if (CALL_P (insn)
+ || can_throw_external (insn))
bitmap_set_bit (blocks_with_calls, bb);
else
{
diff --git a/gcc/gcse.cc b/gcc/gcse.cc
index f06278a5534..b138e1e501c 100644
--- a/gcc/gcse.cc
+++ b/gcc/gcse.cc
@@ -1535,13 +1535,14 @@ compute_hash_table_work (struct gcse_hash_table_d
*table)
= insn_callee_abi (insn).full_and_partial_reg_clobbers ();
EXECUTE_IF_SET_IN_HARD_REG_SET (callee_clobbers, 0, regno, hrsi)
record_last_reg_set_info (insn, regno);
-
- if (! RTL_CONST_OR_PURE_CALL_P (insn)
- || RTL_LOOPING_CONST_OR_PURE_CALL_P (insn)
- || can_throw_external (insn))
- record_last_mem_set_info (insn);
}
+ if ((CALL_P (insn)
+ && (! RTL_CONST_OR_PURE_CALL_P (insn)
+ || RTL_LOOPING_CONST_OR_PURE_CALL_P (insn)))
+ || can_throw_external (insn))
+ record_last_mem_set_info (insn);
+
note_stores (insn, record_last_set_info, insn);
}
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug rtl-optimization/106078] RTL PRE with non-call-exceptions
2022-06-24 11:21 [Bug middle-end/106078] New: Invalid loop invariant motion with non-call-exceptions hubicka at gcc dot gnu.org
` (5 preceding siblings ...)
2022-07-22 10:24 ` [Bug rtl-optimization/106078] RTL PRE " rguenth at gcc dot gnu.org
@ 2022-07-22 10:27 ` rguenth at gcc dot gnu.org
6 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-07-22 10:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106078
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
I split out the inifinite loop case to PR106408.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-07-22 10:27 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-24 11:21 [Bug middle-end/106078] New: Invalid loop invariant motion with non-call-exceptions hubicka at gcc dot gnu.org
2022-06-24 11:40 ` [Bug middle-end/106078] " hubicka at gcc dot gnu.org
2022-06-24 12:58 ` rguenth at gcc dot gnu.org
2022-06-24 13:00 ` rguenth at gcc dot gnu.org
2022-06-24 13:01 ` rguenth at gcc dot gnu.org
2022-06-25 13:33 ` Jan Hubicka
2022-06-25 13:33 ` hubicka at kam dot mff.cuni.cz
2022-07-22 10:24 ` [Bug rtl-optimization/106078] RTL PRE " rguenth at gcc dot gnu.org
2022-07-22 10:27 ` rguenth 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).