From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 41BE93865C2A; Thu, 24 Mar 2022 03:05:27 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 41BE93865C2A
From: "guihaoc at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/105030] store motion if-change flag causes
 if-conversion optimization can't be taken.
Date: Thu, 24 Mar 2022 03:05:27 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 12.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: guihaoc at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-105030-4-zWBKjMhyMj@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-105030-4@http.gcc.gnu.org/bugzilla/>
References: <bug-105030-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Mar 2022 03:05:27 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105030

--- Comment #3 from HaoChen Gui <guihaoc at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> That occured to me as well - I think the answer is maybe.  In principle
> foo() could launch a thread and make the 'atemp' available to it.  As long
> as foo() outlives thread termination that should be all well-defined and =
so
> we'd have to take this possibility into account.
>=20
> There's currently no code ruling this out and doing that is likely diffic=
ult.
> So maybe the answer is to add -fallow-store-data-races=3D{local,all}, map
> -fallow-store-data-races to -fallow-store-data-races=3Dall and make
> -fallow-store-data-races=3Dlocal the default?

For the local automatic variables(not global, not static), they should be
stored on one's own thread stack. I think they can't be accessed by other
threads. Other threads should create their own instance for the local autom=
atic
variables. So 'atemp' is thread safe in the example code? Could you please
explain why it's unsafe when foo outlives thread termination? Thanks a lot.

diff --git a/gcc/tree-ssa-loop-im.cc b/gcc/tree-ssa-loop-im.cc
index 6d9316eed1f..e2b6b927351 100644
--- a/gcc/tree-ssa-loop-im.cc
+++ b/gcc/tree-ssa-loop-im.cc
@@ -2219,7 +2219,10 @@ execute_sm (class loop *loop, im_mem_ref *ref,
   bool always_stored =3D ref_always_accessed_p (loop, ref, true);
   if (maybe_mt
       && (bb_in_transaction (loop_preheader_edge (loop)->src)
-         || (! flag_store_data_races && ! always_stored)))
+         || (! flag_store_data_races && ! always_stored
+             && (!auto_var_in_fn_p (ref->mem.ref, current_function_decl)
+                 || TREE_THIS_VOLATILE (ref->mem.ref)
+                 || TREE_STATIC (ref->mem.ref)))))
     multi_threaded_model_p =3D true;

Could we use above conditions to exclude local auto variables from
multi-threaded safe considerations?=