On Fri, Sep 09, 2011 at 09:09:27PM -0400, Geert Bosch wrote:
> To be honest, I can't quite see the use of completely unordered
> atomic operations, where we not even prohibit compiler optimizations.
> It would seem if we guarantee that a variable will not be accessed
> concurrently from any other t
On Sat, Sep 10, 2011 at 03:09, Geert Bosch wrote:
> For example, for atomic objects accessed only from a single processor
> (but possibly multiple threads), you'd not want the compiler to reorder
> memory accesses to global variables across the atomic operations, but
> you wouldn't have to emit
On Sep 9, 2011, at 04:17, Jakub Jelinek wrote:
> 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 s
On 9/7/11, Vladimir Makarov wrote:
> Some people asked me to do comparison of GCC-4.6 and LLVM-2.9 (both
> released this spring) as I did GCC-LLVM comparison in previous year.
>
> You can find it on http://vmakarov.fedorapeople.org/spec under
> 2011 GCC-LLVM comparison tab entry.
The format of t
Snapshot gcc-4.6-20110909 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110909/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 09/08/2011 08:20 PM, Amker.Cheng wrote:
Hi,
In ifcvt.c's function find_if_case_2, it uses cheap_bb_rtx_cost_p to
judge the conversion.
Function cheap_bb_rtx_cost_p checks whether the total insn_rtx_cost on
non-jump insns in
basic block BB is less than MAX_COST.
So the question is why uses ch
On 09/09/2011 03:09 AM, Jakub Jelinek wrote:
Status
==
The trunk is in Stage 1, which, if we follow roughly the 4.6
release schedule, should end around end of October.
At this point I'd like to gather the status of the various
development branches that haven't been merged into trunk yet
and
On Fri, Sep 09, 2011 at 10:26:22AM -0400, Vladimir Makarov wrote:
> Yes, Jakub. It would be better to use corei7 with avx for GCC.
> Unfortunately, the last tuning which llvm 2.9 supports is core2
> therefore I used -march=core2 for comparison on x86-64. So I think
> it would be unfair to use cor
On 09/09/2011 04:22 PM, Andrew MacLeod wrote:
Yeah, some of this is part of the ongoing C++0x work... the memory model
parameter is going to allow certain types of code movement in optimizers
based on whether its an acquire operation, a release operation, neither,
or both.It is ongoing and
On 09/08/2011 04:47 AM, Jakub Jelinek wrote:
On Wed, Sep 07, 2011 at 11:15:39AM -0400, Vladimir Makarov wrote:
This year I used -Ofast -flto -fwhole-program instead of
-O3 for GCC and -O3 -ffast-math for LLVM for comparison of peak
performance. I could improve GCC performance even more by us
On 09/09/2011 04:17 AM, Jakub Jelinek wrote:
On Fri, Sep 09, 2011 at 10:07:30AM +0200, Paolo Bonzini wrote:
sync builtins are described in the documentations as being full
memory barriers, with the possible exception of
__sync_lock_test_and_set. However, GCC is not enforcing the fact
that they a
On 09/07/2011 12:23 PM, Vladimir Makarov wrote:
On 09/07/2011 11:55 AM, Xinliang David Li wrote:
Why is lto/whole program mode not used in LLVM for peak performance
comparison? (of course, peak performance should really use FDO..)
Thanks for the feedback. I did not manage to use LTO for LLVM a
On 09/09/2011 03:09 AM, Jakub Jelinek wrote:
In particular, is transactional-memory branch mergeable within
a month and half, at least some parts of cxx-mem-model branch,
There will certainly be some parts of the branch which would be
appropriate for merging with mainline in october. We ough
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
On Fri, Sep 09, 2011 at 10:07:30AM +0200, Paolo Bonzini wrote:
> sync builtins are described in the documentations as being full
> memory barriers, with the possible exception of
> __sync_lock_test_and_set. However, GCC is not enforcing the fact
> that they are also full _optimization_ barriers. T
Hi all,
sync builtins are described in the documentations as being full memory
barriers, with the possible exception of __sync_lock_test_and_set.
However, GCC is not enforcing the fact that they are also full
_optimization_ barriers. The RTL produced by builtins does not in
general include a
On Fri, Sep 9, 2011 at 9:09 AM, Jakub Jelinek wrote:
> Status
> ==
>
> The trunk is in Stage 1, which, if we follow roughly the 4.6
> release schedule, should end around end of October.
> At this point I'd like to gather the status of the various
> development branches that haven't been merged
Status
==
The trunk is in Stage 1, which, if we follow roughly the 4.6
release schedule, should end around end of October.
At this point I'd like to gather the status of the various
development branches that haven't been merged into trunk yet
and whether it is possible to merge them with such
18 matches
Mail list logo
