public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ramana Radhakrishnan <ramana.radhakrishnan@foss.arm.com>
To: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,  jason@redhat.com
Cc: David Edelsohn <dje.gcc@gmail.com>,
	wilson@tuliptree.org,  Steve Ellcey <sellcey@mips.com>,
	Richard Henderson <rth@redhat.com>
Subject: [RFC / CFT] PR c++/66192 -  Remove TARGET_RELAXED_ORDERING and use load acquires.
Date: Fri, 22 May 2015 11:26:00 -0000	[thread overview]
Message-ID: <555F1143.4070606@foss.arm.com> (raw)

All,


	This patch removes the special casing for targets with relaxed memory 
ordering and handles guard accesses with equivalent atomic load acquire 
operations. In this process we change the algorithm to load the guard 
variable with an atomic load that has ACQUIRE semantics. I'm not 
terribly familiar with the C++ front-end so I'm not sure I've used the 
appropriate interfaces for doing something like this.

This then means that on targets which have weak memory models, the fast 
path is inlined and can directly use a load-acquire instruction where 
available (and yay! one more hook gone).

Currently bootstrapping and regression testing on AArch64 and ARM (prior 
to the commit that caused PR66241). If this goes in then I'm happy to 
withdraw part of the patches to trunk for AArch64 / ARM that defines 
TARGET_RELAXED_ORDERING and only propose those hunks to the branches.

I'd also request the other target maintainers CC'd to help by testing 
this on their platforms as I do not have access to all of them.

To help folks see the difference, this is the difference in output for a 
compiler for AArch64 built with TARGET_RELAXED_ORDERING set to true and 
this patch for the testcase below.


int* f(void) {
   static int* p = new int;
   return p;
}

-       adrp    x19, .LANCHOR0
-       add     x20, x19, :lo12:.LANCHOR0
-       mov     x0, x20
-       bl      __cxa_guard_acquire
-       cbnz    w0, .L2
-       ldr     x0, [x20, 8]
+       adrp    x20, .LANCHOR0
+       add     x19, x20, :lo12:.LANCHOR0
+       ldar    x0, [x19]
+       tbz     x0, 0, .L11
+.L9:
+       ldr     x0, [x19, 8]



regards
Ramana

2015-05-22  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.

gcc/cp/ChangeLog:

2015-05-22  Ramana Radhakrishnan  <ramana.radhakrishnan@arm.com>

     PR c++/66192
     * decl.c (expand_static_init): Remove special casing for
     targets with weak memory model.
     * decl2.c (build_atomic_load): New function.
      (get_guard_cond): Adjust for atomic_load.

             reply	other threads:[~2015-05-22 11:21 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-22 11:26 Ramana Radhakrishnan [this message]
2015-05-22 11:37 ` Ramana Radhakrishnan
2015-05-22 13:49   ` Jason Merrill
2015-05-22 14:15     ` David Edelsohn
2015-05-22 14:42       ` Jason Merrill
2015-05-22 15:42         ` Ramana Radhakrishnan
2015-05-22 17:48           ` David Edelsohn
2015-05-22 18:19           ` Jason Merrill
2015-05-22 19:49             ` Richard Henderson
2015-05-29 13:32             ` Ramana Radhakrishnan
2015-05-29 16:34               ` Richard Henderson
2015-05-29 16:36               ` Richard Henderson
2015-05-29 20:53               ` Jason Merrill
2015-06-04  9:46                 ` Ramana Radhakrishnan
2015-06-02 14:42               ` David Edelsohn
2015-05-22 14:28     ` Ramana Radhakrishnan
2015-05-24 18:55 Uros Bizjak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=555F1143.4070606@foss.arm.com \
    --to=ramana.radhakrishnan@foss.arm.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    --cc=rth@redhat.com \
    --cc=sellcey@mips.com \
    --cc=wilson@tuliptree.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).