* 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).