novops attribute for external use?
On 04/12/2010 05:27 PM, Bingfeng Mei wrote:
Hello,
One of our engineers requested a feature so that
compiler can avoid to re-load variables after a function
call if it is known not to write to memory. It should
slash considerable code size in our
));
or even
volatile int dummy = pure_fn ();
Richard.
Bingfeng
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
Behalf Of Andrew Haley
Sent: 12 April 2010 17:34
To: gcc@gcc.gnu.org
Subject: Re: Release novops attribute for external use?
On 04/12/2010
On 04/13/2010 10:45 AM, Richard Guenther wrote:
On Tue, Apr 13, 2010 at 10:55 AM, Bingfeng Mei b...@broadcom.com wrote:
Something like printf (Though I read somewhere glibc extension of printf
make it non-pure).
Surely printf writes to global memory (it clobbers the stdout FILE*)
I suppose
Haley
Sent: 12 April 2010 17:34
To: gcc@gcc.gnu.org
Subject: Re: Release novops attribute for external use?
On 04/12/2010 05:27 PM, Bingfeng Mei wrote:
Hello,
One of our engineers requested a feature so that
compiler can avoid to re-load variables after a function
call
attribute for external use?
On 04/12/2010 05:27 PM, Bingfeng Mei wrote:
Hello,
One of our engineers requested a feature so that
compiler can avoid to re-load variables after a function
call if it is known not to write to memory. It should
slash considerable code size in our
On Tue, Apr 13, 2010 at 12:23 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, Apr 13, 2010 at 12:15 PM, Bingfeng Mei b...@broadcom.com wrote:
Surely printf writes to global memory (it clobbers the stdout FILE*)
OK, the point is not about whether printf is pure or not. Instead,
...@gmail.com]
Sent: 13 April 2010 11:25
To: Bingfeng Mei
Cc: Andrew Haley; gcc@gcc.gnu.org
Subject: Re: Release novops attribute for external use?
On Tue, Apr 13, 2010 at 12:23 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, Apr 13, 2010 at 12:15 PM, Bingfeng Mei
b
On 13 April 2010 12:23, Richard Guenther richard.guent...@gmail.com wrote:
On Tue, Apr 13, 2010 at 12:15 PM, Bingfeng Mei b...@broadcom.com wrote:
Surely printf writes to global memory (it clobbers the stdout FILE*)
OK, the point is not about whether printf is pure or not. Instead, if
On Tue, Apr 13, 2010 at 1:35 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 13 April 2010 12:23, Richard Guenther richard.guent...@gmail.com wrote:
On Tue, Apr 13, 2010 at 12:15 PM, Bingfeng Mei b...@broadcom.com wrote:
Surely printf writes to global memory (it clobbers the stdout
Hello,
One of our engineers requested a feature so that
compiler can avoid to re-load variables after a function
call if it is known not to write to memory. It should
slash considerable code size in our applications. I found
the existing pure and const cannot meet his requirements
because the
On 04/12/2010 05:27 PM, Bingfeng Mei wrote:
Hello,
One of our engineers requested a feature so that
compiler can avoid to re-load variables after a function
call if it is known not to write to memory. It should
slash considerable code size in our applications. I found
the existing pure and
On 12/04/2010 17:33, Andrew Haley wrote:
On 04/12/2010 05:27 PM, Bingfeng Mei wrote:
Hello,
One of our engineers requested a feature so that
compiler can avoid to re-load variables after a function
call if it is known not to write to memory. It should
slash considerable code size in our
On 04/12/2010 07:22 PM, Dave Korn wrote:
On 12/04/2010 17:33, Andrew Haley wrote:
On 04/12/2010 05:27 PM, Bingfeng Mei wrote:
Hello,
One of our engineers requested a feature so that
compiler can avoid to re-load variables after a function
call if it is known not to write to memory. It should
On 12/04/2010 19:04, Andrew Haley wrote:
I was thinking about non-memory-mapped I/O, a la x86 I/O ports.
I've always thought that was a bad misnomer. Isn't it just an alternative
memory-mapped address space pretty much like main memory (regardless that the
mapped devices may have some
On Mon, Apr 12, 2010 at 07:47:31PM +0100, Dave Korn wrote:
On 12/04/2010 19:04, Andrew Haley wrote:
I was thinking about non-memory-mapped I/O, a la x86 I/O ports.
I've always thought that was a bad misnomer. Isn't it just an alternative
memory-mapped address space pretty much like
15 matches
Mail list logo
