This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: should sync builtins be full optimization barriers?

From: Paolo Bonzini <bonzini at gnu dot org>
To: Geert Bosch <bosch at adacore dot com>
Cc: Andrew MacLeod <amacleod at redhat dot com>, Jakub Jelinek <jakub at redhat dot com>, GCC Mailing List <gcc at gcc dot gnu dot org>, Aldy Hernandez <aldyh at redhat dot com>
Date: Mon, 12 Sep 2011 09:02:40 +0200
Subject: Re: should sync builtins be full optimization barriers?
References: <4E69C942.3090808@gnu.org> <20110909081705.GT2687@tyan-ft48-01.lab.bos.redhat.com> <5F13A1A0-79E5-4733-B543-4A6F6311A247@adacore.com> <4E6CC1E4.5000000@redhat.com> <93C7346D-DC47-4C6B-9755-EF438D82DDEA@adacore.com>

On 09/11/2011 09:00 PM, Geert Bosch wrote:

So, if I understand correctly, then operations using relaxed memory
order will still need fences, but indeed do not require any
optimization barrier. For memory_order_seq_cst we'll need a full
barrier, and for the others there is a partial barrier.

If you do not need an optimization barrier, you do not need a processor barrier either, and vice versa. Optimizations are just another factor that can lead to reordered loads and stores.

Paolo

Follow-Ups:
- Re: should sync builtins be full optimization barriers?
  - From: Geert Bosch

References:
- should sync builtins be full optimization barriers?
  - From: Paolo Bonzini
- Re: should sync builtins be full optimization barriers?
  - From: Jakub Jelinek
- Re: should sync builtins be full optimization barriers?
  - From: Geert Bosch
- Re: should sync builtins be full optimization barriers?
  - From: Andrew MacLeod
- Re: should sync builtins be full optimization barriers?
  - From: Geert Bosch

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]