Release novops attribute for external use?

Release novops attribute for external use?

[Bingfeng Mei]

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

Re: Release novops attribute for external use?

[Andrew Haley]

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.

Re: Release novops attribute for external use?

[Dave Korn]

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

Re: Release novops attribute for external use?

[Andrew Haley]

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.

Re: Release novops attribute for external use?

[Dave Korn]

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

Re: Release novops attribute for external use?

[Daniel Jacobowitz]

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

RE: Release novops attribute for external use?

[Bingfeng Mei]

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

Re: Release novops attribute for external use?

[Richard Guenther]

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

Re: Release novops attribute for external use?

[Andrew Haley]

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.

RE: Release novops attribute for external use?

[Bingfeng Mei]

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

Re: Release novops attribute for external use?

[Richard Guenther]

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

Re: Release novops attribute for external use?

[Richard Guenther]

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.

RE: Release novops attribute for external use?

[Bingfeng Mei]

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

Re: Release novops attribute for external use?

[Manuel López-Ibáñez]

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.

Re: Release novops attribute for external use?

[Richard Guenther]

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