This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC / CFT] PR c++/66192 - Remove TARGET_RELAXED_ORDERING and use load acquires.
- From: David Edelsohn <dje dot gcc at gmail dot com>
- To: Ramana Radhakrishnan <ramana dot radhakrishnan at foss dot arm dot com>
- Cc: Jason Merrill <jason at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Jim Wilson <wilson at tuliptree dot org>, Steve Ellcey <sellcey at mips dot com>, Richard Henderson <rth at redhat dot com>, Steve Munroe <munroesj at linux dot vnet dot ibm dot com>, Torvald Riegel <triegel at redhat dot com>
- Date: Tue, 2 Jun 2015 10:36:29 -0400
- Subject: Re: [RFC / CFT] PR c++/66192 - Remove TARGET_RELAXED_ORDERING and use load acquires.
- Authentication-results: sourceware.org; auth=none
- References: <555F1143 dot 4070606 at foss dot arm dot com> <555F11B6 dot 1070001 at foss dot arm dot com> <555F31CF dot 6060201 at redhat dot com> <CAGWvnykzukDM2aG_QmbeCyOh7+u6xF8snOc13GUHG2RULoQU-g at mail dot gmail dot com> <555F3D09 dot 2070700 at redhat dot com> <555F49FF dot 1070402 at foss dot arm dot com> <555F6911 dot 6030205 at redhat dot com> <5568673A dot 6060007 at foss dot arm dot com>
On Fri, May 29, 2015 at 9:18 AM, Ramana Radhakrishnan
<ramana.radhakrishnan@foss.arm.com> wrote:
> - Turns build_atomic_load into build_atomic_load_byte in order
> to do an atomic load of 1 byte instead of a full word atomic load.
> - Restructures get_guard_cond to decide whether to use an atomic load
> or a standard load depending on whether code generated will be in
> a multi-threaded context or not.
> - Adjusts all callers of get_guard_cond accordingly.
>
> One of the bits of fallout that I've observed in my testing and that I'm not
> sure about what to do is that on *bare-metal* arm-none-eabi targets we still
> put out calls to __sync_synchronize on architecture versions that do not
> have a barrier instruction which will result in a link error.
>
> While it is tempting to take the easy approach of not putting out the call,
> I suspect in practice a number of users of the bare-metal tools use these
> for their own RTOS's and other micro-OS's. Thus generating barriers at
> higher architecture levels and not generating barriers at lower architecture
> levels appears to be a bit dangerous especially on architectures where there
> is backwards compatibility (i.e. -mcpu=arm7tdmi on standard user code is
> still expected to generate code that works on a core that conforms to a
> later architecture revision).
>
> I am considering leaving this in the ARM backend to force people to think
> what they want to do about thread safety with statics and C++ on bare-metal
> systems. If they really do not want thread safety they can well add
> -fno-threadsafe-statics or provide an appropriate implementation for
> __sync_synchronize on their platforms.
>
> Any thoughts / comments ?
>
> regards
> Ramana
>
> gcc/cp/ChangeLog:
>
> 2015-05-29 Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
>
> PR c++/66192
> * cp-tree.h (get_guard_cond): Adjust declaration
> * decl.c (expand_static_init): Use atomic load acquire
> and adjust call to get_guard_cond.
> * decl2.c (build_atomic_load_byte): New function.
> (get_guard_cond): Handle thread_safety.
> (one_static_initialization_or_destruction): Adjust call to
> get_guard_cond.
>
> gcc/ChangeLog:
>
> 2015-05-29 Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
>
>
> PR c++/66192
> * config/alpha/alpha.c (TARGET_RELAXED_ORDERING): Likewise.
> * config/ia64/ia64.c (TARGET_RELAXED_ORDERING): Likewise.
> * config/rs6000/rs6000.c (TARGET_RELAXED_ORDERING): Likewise.
> * config/sparc/linux.h (SPARC_RELAXED_ORDERING): Likewise.
> * config/sparc/linux64.h (SPARC_RELAXED_ORDERING): Likewise.
> * config/sparc/sparc.c (TARGET_RELAXED_ORDERING): Likewise.
> * config/sparc/sparc.h (SPARC_RELAXED_ORDERING): Likewise.
> * doc/tm.texi: Regenerate.
> * doc/tm.texi.in (TARGET_RELAXED_ORDERING): Delete.
> * target.def (TARGET_RELAXED_ORDERING): Delete.
Bootstrap on PPC64 BE and LE Linux successful. The generated code
looks like what we expect and much better than the current code
generation.
Thanks, David