Re: Request for discussion: Rewrite of inline assembler docs

dw writes: > On 2/27/2014 4:11 AM, Richard Sandiford wrote: >> Andrew Haley writes: >>> Over the years there has been a great deal of traffic on these lists >>> caused by misunderstandings of GCC's inline assembler. That's partly >>> because it's inherently tricky, but the existing documentation

RE: Asm volatile causing performance regressions on ARM

Hello! > > This code (introduced in > > http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=193802) aborts > > CSE after seeing a volatile inline asm. > > Note that "introduced" is not really correct here, the code had been > there for a long time but it was treating some volatile asms as > ba

Re: Asm volatile causing performance regressions on ARM

> asm volatile + memory clobber should be the last resort barrier, if you skip > this out of the compiler or change its semantics (pinned by the current > documentation) at will, it's not unlikely you break existing code in favour > or saving some poor instructions. Problem is that there is no cur

Re: Request for discussion: Rewrite of inline assembler docs

dw writes: > > What would you say to something like this: > > "Since GCC does not parse the asm, it has no visibility of any static > variables or functions it references. This may result in those > symbols getting discarded by GCC as unused. To avoid this problem, > list the symbols as inputs o

Re: Request for discussion: Rewrite of inline assembler docs

On 2/27/2014 9:35 AM, Andi Kleen wrote: Andrew Haley writes: Over the years there has been a great deal of traffic on these lists caused by misunderstandings of GCC's inline assembler. That's partly because it's inherently tricky, but the existing documentation needs to be improved. dw has

Re: Request for discussion: Rewrite of inline assembler docs

On 2/27/2014 4:22 AM, Kyrill Tkachov wrote: On 27/02/14 11:07, Andrew Haley wrote: Over the years there has been a great deal of traffic on these lists caused by misunderstandings of GCC's inline assembler. That's partly because it's inherently tricky, but the existing documentation needs to b

Re: Request for discussion: Rewrite of inline assembler docs

On 2/27/2014 4:11 AM, Richard Sandiford wrote: Andrew Haley writes: Over the years there has been a great deal of traffic on these lists caused by misunderstandings of GCC's inline assembler. That's partly because it's inherently tricky, but the existing documentation needs to be improved. d

Re: [RFC][PATCH 0/5] arch: atomic rework

On Thu, Feb 27, 2014 at 09:50:21AM -0800, Paul E. McKenney wrote: > On Thu, Feb 27, 2014 at 04:37:33PM +0100, Torvald Riegel wrote: > > xagsmtp2.20140227154925.3...@vmsdvm9.vnet.ibm.com > > > > On Mon, 2014-02-24 at 11:54 -0800, Linus Torvalds wrote: > > > On Mon, Feb 24, 2014 at 10:53 AM, Paul E.

gcc-4.8-20140227 is now available

Snapshot gcc-4.8-20140227 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20140227/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

Re: [RFC][PATCH 0/5] arch: atomic rework

On Thu, Feb 27, 2014 at 11:47:08AM -0800, Linus Torvalds wrote: > On Thu, Feb 27, 2014 at 11:06 AM, Paul E. McKenney > wrote: > > > > 3. The comparison was against another RCU-protected pointer, > > where that other pointer was properly fetched using one > > of the RCU primiti

Re: About gsoc 2014 OpenMP 4.0 Projects

Hi Güray! Giving some pointers here (but this is not a complete list), to announcements and a few discussion threads, that should already answer some of your questions, give an idea who's currently working on what:

Re: Asm volatile causing performance regressions on ARM

Yury Gribov schrieb: Richard Biener wrote: If this behavior is not intended, what would be the best way to fix performance? I could teach GCC to not remove constant RTXs in flush_hash_table() but this is probably very naive and won't cover some corner-cases. That could be a good starting point

Re: [RFC][PATCH 0/5] arch: atomic rework

On Thu, Feb 27, 2014 at 11:06 AM, Paul E. McKenney wrote: > > 3. The comparison was against another RCU-protected pointer, > where that other pointer was properly fetched using one > of the RCU primitives. Here it doesn't matter which pointer > you use. At least as l

Re: [RFC][PATCH 0/5] arch: atomic rework

On Thu, Feb 27, 2014 at 09:50:21AM -0800, Paul E. McKenney wrote: > On Thu, Feb 27, 2014 at 04:37:33PM +0100, Torvald Riegel wrote: > > xagsmtp2.20140227154925.3...@vmsdvm9.vnet.ibm.com > > > > On Mon, 2014-02-24 at 11:54 -0800, Linus Torvalds wrote: > > > On Mon, Feb 24, 2014 at 10:53 AM, Paul E.

Re: [RFC][PATCH 0/5] arch: atomic rework

On Thu, Feb 27, 2014 at 09:01:40AM -0800, Linus Torvalds wrote: > On Thu, Feb 27, 2014 at 7:37 AM, Torvald Riegel wrote: > > > > I agree that just considering syntactic properties of the program seems > > to be insufficient. Making it instead depend on whether there is a > > "semantic" dependency

Re: [RFC][PATCH 0/5] arch: atomic rework

On Thu, Feb 27, 2014 at 04:37:33PM +0100, Torvald Riegel wrote: > xagsmtp2.20140227154925.3...@vmsdvm9.vnet.ibm.com > > On Mon, 2014-02-24 at 11:54 -0800, Linus Torvalds wrote: > > On Mon, Feb 24, 2014 at 10:53 AM, Paul E. McKenney > > wrote: > > > > > > Good points. How about the following repl

Re: Request for discussion: Rewrite of inline assembler docs

Andrew Haley writes: > Over the years there has been a great deal of traffic on these lists > caused by misunderstandings of GCC's inline assembler. That's partly > because it's inherently tricky, but the existing documentation needs > to be improved. > > dw has done a fairly thorough reworking

Re: About gsoc 2014 OpenMP 4.0 Projects

Hi Evgeny, As i said, I'm working for source-to-source generation for my master thesis. But my compiler can transform from C to CUDA not PTX now :) For further information, I uploaded https://github.com/grypp/macc-omp4 my documents and code samples regarding my master thesis. I also added my bench

Re: Asm volatile causing performance regressions on ARM

Hi, On Thu, 27 Feb 2014, Richard Sandiford wrote: > [... many cases where 'volatile' in asm doesn't inhibit optimizations > ...] > > We do nothing this draconian for a normal function call, which could > easily use a volatile asm internally. IMO anything that isn't flushed > for a call shouldn

Re: Asm volatile causing performance regressions on ARM

On 27/02/14 16:36, Yury Gribov wrote: > Richard Biener wrote: If this behavior is not intended, what would be the best way to fix performance? I could teach GCC to not remove constant RTXs in flush_hash_table() but this is probably very naive and won't cover some corner-cases. >

Re: Asm volatile causing performance regressions on ARM

Yury Gribov writes: > Richard Biener wrote: If this behavior is not intended, what would be the best way to fix performance? I could teach GCC to not remove constant RTXs in flush_hash_table() but this is probably very naive and won't cover some corner-cases. >>> >>> That could

Re: [RFC][PATCH 0/5] arch: atomic rework

On Thu, Feb 27, 2014 at 7:37 AM, Torvald Riegel wrote: > > I agree that just considering syntactic properties of the program seems > to be insufficient. Making it instead depend on whether there is a > "semantic" dependency due to a value being "necessary" to compute a > result seems better. How

Re: [RFC][PATCH 0/5] arch: atomic rework

On Mon, 2014-02-24 at 11:54 -0800, Linus Torvalds wrote: > On Mon, Feb 24, 2014 at 10:53 AM, Paul E. McKenney > wrote: > > > > Good points. How about the following replacements? > > > > 3. Adding or subtracting an integer to/from a chained pointer > > results in another chained point

Re: Asm volatile causing performance regressions on ARM

Richard Biener wrote: If this behavior is not intended, what would be the best way to fix performance? I could teach GCC to not remove constant RTXs in flush_hash_table() but this is probably very naive and won't cover some corner-cases. That could be a good starting point though. Though with

Re: Asm volatile causing performance regressions on ARM

On Thu, Feb 27, 2014 at 4:02 PM, Eric Botcazou wrote: >> After some investigation, we discovered that this behavior is caused by >> big hammer in gcc/cse.c: >> /* A volatile ASM or an UNSPEC_VOLATILE invalidates everything. */ >> if (NONJUMP_INSN_P (insn) >> && volatile_insn_p (PA

Re: Asm volatile causing performance regressions on ARM

> After some investigation, we discovered that this behavior is caused by > big hammer in gcc/cse.c: > /* A volatile ASM or an UNSPEC_VOLATILE invalidates everything. */ > if (NONJUMP_INSN_P (insn) > && volatile_insn_p (PATTERN (insn))) > flush_hash_table (); > This code (int

[RFC] Meta-description for tree and gimple folding

I've been hacking on a prototype that generates matching and simplification code from a meta-description. The goal is to provide a single source of transforms currently spread over the compiler, mostly fold-const.c, gimple-fold.c and tree-ssa-forwprop.c. Another goal is to make these transforms

Asm volatile causing performance regressions on ARM

Hi all, We have recently ran into a performance/code size regression on ARM targets after transition from GCC 4.7 to GCC 4.8 (this regression is also present in 4.9). The following code snippet uses Linux-style compiler barriers to protect memory writes: #define barrier() __asm__ __volat

Re: proposal to turn on some warnings by default

On Thu, 2014-02-27 at 10:14 +0100, David Brown wrote: > On 27/02/14 07:50, Mingjie Xing wrote: > > Hello, > > > > I'm wondering if it's a good idea to turn on some warnings by default > > (or even promote them to error), such as -Wreturn-type on C. This > > would help programmers to avoid some mi

Re: Request for discussion: Rewrite of inline assembler docs

On 27/02/14 11:07, Andrew Haley wrote: Over the years there has been a great deal of traffic on these lists caused by misunderstandings of GCC's inline assembler. That's partly because it's inherently tricky, but the existing documentation needs to be improved. dw has done a fairly thorough re

Re: Request for discussion: Rewrite of inline assembler docs

Andrew Haley writes: > Over the years there has been a great deal of traffic on these lists > caused by misunderstandings of GCC's inline assembler. That's partly > because it's inherently tricky, but the existing documentation needs > to be improved. > > dw has done a fairly thorough reworking

Request for discussion: Rewrite of inline assembler docs

Over the years there has been a great deal of traffic on these lists caused by misunderstandings of GCC's inline assembler. That's partly because it's inherently tricky, but the existing documentation needs to be improved. dw has done a fairly thorough reworking of the documentation. I've helpe

Re: proposal to turn on some warnings by default

On 27/02/2014 07:50, Mingjie Xing wrote: > Hello, > > I'm wondering if it's a good idea to turn on some warnings by default > (or even promote them to error), such as -Wreturn-type on C. This > would help programmers to avoid some mistakes. > I am writing a patch for this specific change but it is

Re: proposal to turn on some warnings by default

On 27/02/14 07:50, Mingjie Xing wrote: > Hello, > > I'm wondering if it's a good idea to turn on some warnings by default > (or even promote them to error), such as -Wreturn-type on C. This > would help programmers to avoid some mistakes. > > Regards, > Mingjie > Personally, I think gcc should