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: Jakub Jelinek <jakub at redhat dot com>
Cc: GCC Mailing List <gcc at gcc dot gnu dot org>, Aldy Hernandez <aldyh at redhat dot com>, amacleod at redhat dot com
Date: Fri, 09 Sep 2011 10:18:13 +0200
Subject: Re: should sync builtins be full optimization barriers?
References: <4E69C942.3090808@gnu.org> <20110909081705.GT2687@tyan-ft48-01.lab.bos.redhat.com>

On 09/09/2011 10:17 AM, Jakub Jelinek wrote:

>  Is the above analysis correct?  Or should the users put explicit
>  compiler barriers?

I'd say they should be optimization barriers too (and at the tree level
they I think work that way, being represented as function calls), so if
they don't act as memory barriers in RTL, the *.md patterns should be
fixed.  The only exception should be IMHO the __SYNC_MEM_RELAXED
variants - if the CPU can reorder memory accesses across them at will,
why shouldn't the compiler be able to do the same as well?

Agreed, so we have a bug in all released versions of GCC. :(

Paolo

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

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