* Release novops attribute for external use?
@ 2010-04-12 16:56 Bingfeng Mei
2010-04-12 16:58 ` Andrew Haley
0 siblings, 1 reply; 15+ messages in thread
From: Bingfeng Mei @ 2010-04-12 16:56 UTC (permalink / raw)
To: gcc
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 function is optimized out if it doesn't return
a value. I almost started to implement a new attribute
in our own port, only to find out "novops" attribute is
exact what we want. Why "novops" is only limited to
internal use? Does it has any other implication? Could
we release this attribute for external use as well?
Thanks,
Bingfeng Mei
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Release novops attribute for external use?
2010-04-12 16:56 Release novops attribute for external use? Bingfeng Mei
@ 2010-04-12 16:58 ` Andrew Haley
2010-04-12 18:05 ` Dave Korn
2010-04-13 9:45 ` Bingfeng Mei
0 siblings, 2 replies; 15+ messages in thread
From: Andrew Haley @ 2010-04-12 16:58 UTC (permalink / raw)
To: gcc
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 "const" cannot meet his requirements
> because the function is optimized out if it doesn't return
> a value.
If a function doesn't write to memory and it doesn't return a
value, what is the point of calling it?
Andrew.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Release novops attribute for external use?
2010-04-12 16:58 ` Andrew Haley
@ 2010-04-12 18:05 ` Dave Korn
2010-04-12 18:10 ` Andrew Haley
2010-04-13 9:45 ` Bingfeng Mei
1 sibling, 1 reply; 15+ messages in thread
From: Dave Korn @ 2010-04-12 18:05 UTC (permalink / raw)
To: Andrew Haley; +Cc: gcc
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 applications. I found
>> the existing "pure" and "const" cannot meet his requirements
>> because the function is optimized out if it doesn't return
>> a value.
>
> If a function doesn't write to memory and it doesn't return a
> value, what is the point of calling it?
Delay-loop! That's about the only thing I can think of anyway :-)
cheers,
DaveK
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Release novops attribute for external use?
2010-04-12 18:05 ` Dave Korn
@ 2010-04-12 18:10 ` Andrew Haley
2010-04-12 18:29 ` Dave Korn
0 siblings, 1 reply; 15+ messages in thread
From: Andrew Haley @ 2010-04-12 18:10 UTC (permalink / raw)
To: Dave Korn; +Cc: gcc
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
>>> slash considerable code size in our applications. I found
>>> the existing "pure" and "const" cannot meet his requirements
>>> because the function is optimized out if it doesn't return
>>> a value.
>>
>> If a function doesn't write to memory and it doesn't return a
>> value, what is the point of calling it?
>
> Delay-loop! That's about the only thing I can think of anyway :-)
I was thinking about non-memory-mapped I/O, a la x86 I/O ports. But
yeah. :-)
Andrew.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Release novops attribute for external use?
2010-04-12 18:10 ` Andrew Haley
@ 2010-04-12 18:29 ` Dave Korn
2010-04-12 20:53 ` Daniel Jacobowitz
0 siblings, 1 reply; 15+ messages in thread
From: Dave Korn @ 2010-04-12 18:29 UTC (permalink / raw)
To: Andrew Haley; +Cc: Dave Korn, gcc
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 fairly non-standard characteristics)? Certainly
from the compiler's point of view it's got to count as "memory"; it's
somewhere values come from and go to and are "externally visible".
cheers,
DaveK
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Release novops attribute for external use?
2010-04-12 18:29 ` Dave Korn
@ 2010-04-12 20:53 ` Daniel Jacobowitz
0 siblings, 0 replies; 15+ messages in thread
From: Daniel Jacobowitz @ 2010-04-12 20:53 UTC (permalink / raw)
To: Dave Korn; +Cc: Andrew Haley, gcc
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 main memory (regardless that the
> mapped devices may have some fairly non-standard characteristics)? Certainly
> from the compiler's point of view it's got to count as "memory"; it's
> somewhere values come from and go to and are "externally visible".
Then you can think about it as "does not alias any non-device
memory", or any number of variants on that.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: Release novops attribute for external use?
2010-04-12 16:58 ` Andrew Haley
2010-04-12 18:05 ` Dave Korn
@ 2010-04-13 9:45 ` Bingfeng Mei
2010-04-13 9:56 ` Richard Guenther
1 sibling, 1 reply; 15+ messages in thread
From: Bingfeng Mei @ 2010-04-13 9:45 UTC (permalink / raw)
To: Andrew Haley, gcc
Something like printf (Though I read somewhere glibc extension of printf
make it non-pure).
Bingfeng
> -----Original Message-----
> From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@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 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 "const" cannot meet his requirements
> > because the function is optimized out if it doesn't return
> > a value.
>
> If a function doesn't write to memory and it doesn't return a
> value, what is the point of calling it?
>
> Andrew.
>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Release novops attribute for external use?
2010-04-13 9:45 ` Bingfeng Mei
@ 2010-04-13 9:56 ` Richard Guenther
2010-04-13 10:15 ` Andrew Haley
2010-04-13 10:23 ` Bingfeng Mei
0 siblings, 2 replies; 15+ messages in thread
From: Richard Guenther @ 2010-04-13 9:56 UTC (permalink / raw)
To: Bingfeng Mei; +Cc: Andrew Haley, gcc
On Tue, Apr 13, 2010 at 10:55 AM, Bingfeng Mei <bmei@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*)
As for the original question - novops is internal only because its
semantics is purely internal and changes with internal aliasing
changes.
Now, we still lack a compelling example to see what exact semantics
you are requesting? I suppose it might be close to a pure but
volatile function? Which you could simulate by
dummy = pure_fn ();
asm ("" : "g" (dummy));
or even
volatile int dummy = pure_fn ();
Richard.
> Bingfeng
>
>> -----Original Message-----
>> From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@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 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 "const" cannot meet his requirements
>> > because the function is optimized out if it doesn't return
>> > a value.
>>
>> If a function doesn't write to memory and it doesn't return a
>> value, what is the point of calling it?
>>
>> Andrew.
>>
>>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Release novops attribute for external use?
2010-04-13 9:56 ` Richard Guenther
@ 2010-04-13 10:15 ` Andrew Haley
2010-04-13 10:23 ` Bingfeng Mei
1 sibling, 0 replies; 15+ messages in thread
From: Andrew Haley @ 2010-04-13 10:15 UTC (permalink / raw)
To: gcc
On 04/13/2010 10:45 AM, Richard Guenther wrote:
> On Tue, Apr 13, 2010 at 10:55 AM, Bingfeng Mei <bmei@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 a system call to something such as sync(2) is something with
a side-effect that does not touch memory, or at least the memory of
the process calling it. But you still don't want to reorder calls to
such functions, even though they don't clobber memory.
I think the semantics of this are going to be extremely hard to define
unambiguously.
Andrew.
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: Release novops attribute for external use?
2010-04-13 9:56 ` Richard Guenther
2010-04-13 10:15 ` Andrew Haley
@ 2010-04-13 10:23 ` Bingfeng Mei
2010-04-13 10:25 ` Richard Guenther
1 sibling, 1 reply; 15+ messages in thread
From: Bingfeng Mei @ 2010-04-13 10:23 UTC (permalink / raw)
To: Richard Guenther; +Cc: Andrew Haley, gcc
>
> 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
programmer knows the callee function such as printf contains no
memory access that affects operations inside caller function, and he
would like to have a way to optimize the code. Our engineer gave following
example:
void myfunc(MyStruct *myStruct)
{
int a,b;
a = myStruct->a;
printf("a=%d\n",a);
b = 2*mystruct->a; // I would like to have the compiler acting as if I had written b = 2*a;
...
}
Providing such attribute may be potentially dangerous. But it is just
like "restrict" qualifier and some other attributes, putting responsibilty
of correctness on the programmer. "novops" seems to achieve that effect,
though its semantics doesn't match exactly what I described.
> As for the original question - novops is internal only because its
> semantics is purely internal and changes with internal aliasing
> changes.
>
> Now, we still lack a compelling example to see what exact semantics
> you are requesting? I suppose it might be close to a pure but
> volatile function? Which you could simulate by
>
> dummy = pure_fn ();
> asm ("" : "g" (dummy));
>
> or even
>
> volatile int dummy = pure_fn ();
These two methods still generate extra code to reload variables
Bingfeng
>
> Richard.
>
> > Bingfeng
> >
> >> -----Original Message-----
> >> From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@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 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 "const" cannot meet his requirements
> >> > because the function is optimized out if it doesn't return
> >> > a value.
> >>
> >> If a function doesn't write to memory and it doesn't return a
> >> value, what is the point of calling it?
> >>
> >> Andrew.
> >>
> >>
> >
>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Release novops attribute for external use?
2010-04-13 10:23 ` Bingfeng Mei
@ 2010-04-13 10:25 ` Richard Guenther
2010-04-13 10:57 ` Richard Guenther
2010-04-13 11:53 ` Manuel López-Ibáñez
0 siblings, 2 replies; 15+ messages in thread
From: Richard Guenther @ 2010-04-13 10:25 UTC (permalink / raw)
To: Bingfeng Mei; +Cc: Andrew Haley, gcc
On Tue, Apr 13, 2010 at 12:15 PM, Bingfeng Mei <bmei@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
> programmer knows the callee function such as printf contains no
> memory access that affects operations inside caller function, and he
> would like to have a way to optimize the code. Our engineer gave following
> example:
>
> void myfunc(MyStruct *myStruct)
> {
> int a,b;
> a = myStruct->a;
> printf("a=%d\n",a);
> b = 2*mystruct->a; // I would like to have the compiler acting as if I had written b = 2*a;
> ...
> }
> Providing such attribute may be potentially dangerous. But it is just
> like "restrict" qualifier and some other attributes, putting responsibilty
> of correctness on the programmer. "novops" seems to achieve that effect,
> though its semantics doesn't match exactly what I described.
Indeed. IPA pointer analysis will probably figure it out
automagically - that *myStruct didn't escape the unit.
Being able to annotate incoming pointers this way would
maybe be useful.
>> As for the original question - novops is internal only because its
>> semantics is purely internal and changes with internal aliasing
>> changes.
>>
>> Now, we still lack a compelling example to see what exact semantics
>> you are requesting? I suppose it might be close to a pure but
>> volatile function? Which you could simulate by
>>
>> dummy = pure_fn ();
>> asm ("" : "g" (dummy));
>>
>> or even
>>
>> volatile int dummy = pure_fn ();
>
> These two methods still generate extra code to reload variables
The latter works for me (ok, the store to dummy is retained):
extern int myprintf(int) __attribute__((pure));
int myfunc (int *p)
{
int a;
a = *p;
volatile int dummy = myprintf(a);
return a + *p;
}
myfunc:
.LFB0:
pushq %rbx
.LCFI0:
subq $16, %rsp
.LCFI1:
movl (%rdi), %ebx
movl %ebx, %edi
call myprintf
movl %eax, 12(%rsp)
leal (%rbx,%rbx), %eax
addq $16, %rsp
.LCFI2:
popq %rbx
.LCFI3:
ret
so we load from %rdi only once.
Richard.
> Bingfeng
>
>
>>
>> Richard.
>>
>> > Bingfeng
>> >
>> >> -----Original Message-----
>> >> From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@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 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 "const" cannot meet his requirements
>> >> > because the function is optimized out if it doesn't return
>> >> > a value.
>> >>
>> >> If a function doesn't write to memory and it doesn't return a
>> >> value, what is the point of calling it?
>> >>
>> >> Andrew.
>> >>
>> >>
>> >
>>
>>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Release novops attribute for external use?
2010-04-13 10:25 ` Richard Guenther
@ 2010-04-13 10:57 ` Richard Guenther
2010-04-13 11:35 ` Bingfeng Mei
2010-04-13 11:53 ` Manuel López-Ibáñez
1 sibling, 1 reply; 15+ messages in thread
From: Richard Guenther @ 2010-04-13 10:57 UTC (permalink / raw)
To: Bingfeng Mei; +Cc: Andrew Haley, gcc
On Tue, Apr 13, 2010 at 12:23 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Tue, Apr 13, 2010 at 12:15 PM, Bingfeng Mei <bmei@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
>> programmer knows the callee function such as printf contains no
>> memory access that affects operations inside caller function, and he
>> would like to have a way to optimize the code. Our engineer gave following
>> example:
>>
>> void myfunc(MyStruct *myStruct)
>> {
>> int a,b;
>> a = myStruct->a;
>> printf("a=%d\n",a);
>> b = 2*mystruct->a; // I would like to have the compiler acting as if I had written b = 2*a;
>> ...
>> }
>> Providing such attribute may be potentially dangerous. But it is just
>> like "restrict" qualifier and some other attributes, putting responsibilty
>> of correctness on the programmer. "novops" seems to achieve that effect,
>> though its semantics doesn't match exactly what I described.
>
> Indeed. IPA pointer analysis will probably figure it out
> automagically - that *myStruct didn't escape the unit.
> Being able to annotate incoming pointers this way would
> maybe be useful.
>
>>> As for the original question - novops is internal only because its
>>> semantics is purely internal and changes with internal aliasing
>>> changes.
>>>
>>> Now, we still lack a compelling example to see what exact semantics
>>> you are requesting? I suppose it might be close to a pure but
>>> volatile function? Which you could simulate by
>>>
>>> dummy = pure_fn ();
>>> asm ("" : "g" (dummy));
>>>
>>> or even
>>>
>>> volatile int dummy = pure_fn ();
>>
>> These two methods still generate extra code to reload variables
>
> The latter works for me (ok, the store to dummy is retained):
>
> extern int myprintf(int) __attribute__((pure));
> int myfunc (int *p)
> {
> int a;
> a = *p;
> volatile int dummy = myprintf(a);
> return a + *p;
> }
>
> myfunc:
> .LFB0:
> pushq %rbx
> .LCFI0:
> subq $16, %rsp
> .LCFI1:
> movl (%rdi), %ebx
> movl %ebx, %edi
> call myprintf
> movl %eax, 12(%rsp)
> leal (%rbx,%rbx), %eax
> addq $16, %rsp
> .LCFI2:
> popq %rbx
> .LCFI3:
> ret
>
> so we load from %rdi only once.
And
extern int myprintf(int) __attribute__((pure));
int myfunc (int *p)
{
int a;
a = *p;
int dummy = myprintf(a);
asm ("" : : "g" (dummy));
return a + *p;
}
produces
myfunc:
.LFB0:
pushq %rbx
.LCFI0:
movl (%rdi), %ebx
movl %ebx, %edi
call myprintf
leal (%rbx,%rbx), %eax
popq %rbx
.LCFI1:
ret
even better.
Richard.
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: Release novops attribute for external use?
2010-04-13 10:57 ` Richard Guenther
@ 2010-04-13 11:35 ` Bingfeng Mei
0 siblings, 0 replies; 15+ messages in thread
From: Bingfeng Mei @ 2010-04-13 11:35 UTC (permalink / raw)
To: Richard Guenther; +Cc: gcc
Thanks! I forgot to declare the function as pure. The empty asm
seems to be a clever trick to avoid function being optimized out.
I shall tell our engineers to use this instead of implementing a new
attribute.
Bingfeng
> -----Original Message-----
> From: Richard Guenther [mailto:richard.guenther@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.guenther@gmail.com> wrote:
> > On Tue, Apr 13, 2010 at 12:15 PM, Bingfeng Mei
> <bmei@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
> >> programmer knows the callee function such as printf contains no
> >> memory access that affects operations inside caller
> function, and he
> >> would like to have a way to optimize the code. Our
> engineer gave following
> >> example:
> >>
> >> void myfunc(MyStruct *myStruct)
> >> {
> >> int a,b;
> >> a = myStruct->a;
> >> printf("a=%d\n",a);
> >> b = 2*mystruct->a; // I would like to have the
> compiler acting as if I had written b = 2*a;
> >> ...
> >> }
> >> Providing such attribute may be potentially dangerous. But
> it is just
> >> like "restrict" qualifier and some other attributes,
> putting responsibilty
> >> of correctness on the programmer. "novops" seems to
> achieve that effect,
> >> though its semantics doesn't match exactly what I described.
> >
> > Indeed. IPA pointer analysis will probably figure it out
> > automagically - that *myStruct didn't escape the unit.
> > Being able to annotate incoming pointers this way would
> > maybe be useful.
> >
> >>> As for the original question - novops is internal only because its
> >>> semantics is purely internal and changes with internal aliasing
> >>> changes.
> >>>
> >>> Now, we still lack a compelling example to see what exact
> semantics
> >>> you are requesting? I suppose it might be close to a pure but
> >>> volatile function? Which you could simulate by
> >>>
> >>> dummy = pure_fn ();
> >>> asm ("" : "g" (dummy));
> >>>
> >>> or even
> >>>
> >>> volatile int dummy = pure_fn ();
> >>
> >> These two methods still generate extra code to reload variables
> >
> > The latter works for me (ok, the store to dummy is retained):
> >
> > extern int myprintf(int) __attribute__((pure));
> > int myfunc (int *p)
> > {
> > int a;
> > a = *p;
> > volatile int dummy = myprintf(a);
> > return a + *p;
> > }
> >
> > myfunc:
> > .LFB0:
> > pushq %rbx
> > .LCFI0:
> > subq $16, %rsp
> > .LCFI1:
> > movl (%rdi), %ebx
> > movl %ebx, %edi
> > call myprintf
> > movl %eax, 12(%rsp)
> > leal (%rbx,%rbx), %eax
> > addq $16, %rsp
> > .LCFI2:
> > popq %rbx
> > .LCFI3:
> > ret
> >
> > so we load from %rdi only once.
>
> And
>
> extern int myprintf(int) __attribute__((pure));
> int myfunc (int *p)
> {
> int a;
> a = *p;
> int dummy = myprintf(a);
> asm ("" : : "g" (dummy));
> return a + *p;
> }
>
> produces
>
> myfunc:
> .LFB0:
> pushq %rbx
> .LCFI0:
> movl (%rdi), %ebx
> movl %ebx, %edi
> call myprintf
> leal (%rbx,%rbx), %eax
> popq %rbx
> .LCFI1:
> ret
>
> even better.
>
> Richard.
>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Release novops attribute for external use?
2010-04-13 10:25 ` Richard Guenther
2010-04-13 10:57 ` Richard Guenther
@ 2010-04-13 11:53 ` Manuel López-Ibáñez
2010-04-13 15:06 ` Richard Guenther
1 sibling, 1 reply; 15+ messages in thread
From: Manuel López-Ibáñez @ 2010-04-13 11:53 UTC (permalink / raw)
To: Richard Guenther; +Cc: Bingfeng Mei, Andrew Haley, gcc
On 13 April 2010 12:23, Richard Guenther <richard.guenther@gmail.com> wrote:
> On Tue, Apr 13, 2010 at 12:15 PM, Bingfeng Mei <bmei@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
>> programmer knows the callee function such as printf contains no
>> memory access that affects operations inside caller function, and he
>> would like to have a way to optimize the code. Our engineer gave following
>> example:
>>
>> void myfunc(MyStruct *myStruct)
>> {
>> int a,b;
>> a = myStruct->a;
>> printf("a=%d\n",a);
>> b = 2*mystruct->a; // I would like to have the compiler acting as if I had written b = 2*a;
>> ...
>> }
>> Providing such attribute may be potentially dangerous. But it is just
>> like "restrict" qualifier and some other attributes, putting responsibilty
>> of correctness on the programmer. "novops" seems to achieve that effect,
>> though its semantics doesn't match exactly what I described.
>
> Indeed. IPA pointer analysis will probably figure it out
> automagically - that *myStruct didn't escape the unit.
> Being able to annotate incoming pointers this way would
> maybe be useful.
This is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31893
isn't it?
Cheers,
Manuel.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Release novops attribute for external use?
2010-04-13 11:53 ` Manuel López-Ibáñez
@ 2010-04-13 15:06 ` Richard Guenther
0 siblings, 0 replies; 15+ messages in thread
From: Richard Guenther @ 2010-04-13 15:06 UTC (permalink / raw)
To: Manuel López-Ibáñez; +Cc: Bingfeng Mei, Andrew Haley, gcc
On Tue, Apr 13, 2010 at 1:35 PM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> On 13 April 2010 12:23, Richard Guenther <richard.guenther@gmail.com> wrote:
>> On Tue, Apr 13, 2010 at 12:15 PM, Bingfeng Mei <bmei@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
>>> programmer knows the callee function such as printf contains no
>>> memory access that affects operations inside caller function, and he
>>> would like to have a way to optimize the code. Our engineer gave following
>>> example:
>>>
>>> void myfunc(MyStruct *myStruct)
>>> {
>>> int a,b;
>>> a = myStruct->a;
>>> printf("a=%d\n",a);
>>> b = 2*mystruct->a; // I would like to have the compiler acting as if I had written b = 2*a;
>>> ...
>>> }
>>> Providing such attribute may be potentially dangerous. But it is just
>>> like "restrict" qualifier and some other attributes, putting responsibilty
>>> of correctness on the programmer. "novops" seems to achieve that effect,
>>> though its semantics doesn't match exactly what I described.
>>
>> Indeed. IPA pointer analysis will probably figure it out
>> automagically - that *myStruct didn't escape the unit.
>> Being able to annotate incoming pointers this way would
>> maybe be useful.
>
> This is
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31893
>
> isn't it?
Not really.
Richard.
> Cheers,
>
> Manuel.
>
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2010-04-13 11:53 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-04-12 16:56 Release novops attribute for external use? Bingfeng Mei
2010-04-12 16:58 ` Andrew Haley
2010-04-12 18:05 ` Dave Korn
2010-04-12 18:10 ` Andrew Haley
2010-04-12 18:29 ` Dave Korn
2010-04-12 20:53 ` Daniel Jacobowitz
2010-04-13 9:45 ` Bingfeng Mei
2010-04-13 9:56 ` Richard Guenther
2010-04-13 10:15 ` Andrew Haley
2010-04-13 10:23 ` Bingfeng Mei
2010-04-13 10:25 ` Richard Guenther
2010-04-13 10:57 ` Richard Guenther
2010-04-13 11:35 ` Bingfeng Mei
2010-04-13 11:53 ` Manuel López-Ibáñez
2010-04-13 15:06 ` Richard Guenther
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).