[Bug middle-end/106078] New: Invalid loop invariant motion with non-call-exceptions

[Bug middle-end/106078] New: Invalid loop invariant motion with non-call-exceptions

[hubicka at gcc dot gnu.org]

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.

[Bug middle-end/106078] Invalid loop invariant motion with non-call-exceptions

[hubicka at gcc dot gnu.org]

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;
          }
}

[Bug middle-end/106078] Invalid loop invariant motion with non-call-exceptions

[rguenth at gcc dot gnu.org]

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.

[Bug middle-end/106078] Invalid loop invariant motion with non-call-exceptions

[rguenth at gcc dot gnu.org]

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.

[Bug middle-end/106078] Invalid loop invariant motion with non-call-exceptions

[rguenth at gcc dot gnu.org]

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.

Re: [Bug middle-end/106078] Invalid loop invariant motion with non-call-exceptions

[Jan Hubicka]

> > 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

[Bug middle-end/106078] Invalid loop invariant motion with non-call-exceptions

[hubicka at kam dot mff.cuni.cz]

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

[Bug rtl-optimization/106078] RTL PRE with non-call-exceptions

[rguenth at gcc dot gnu.org]

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);
        }

[Bug rtl-optimization/106078] RTL PRE with non-call-exceptions

[rguenth at gcc dot gnu.org]

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.