Re: Should we create an attribute malloc for supposed alias benefits?

Re: Should we create an attribute malloc for supposed alias benefits?

[Kaveh R. Ghazi]

 > From: Mark Mitchell <mark@codesourcery.com>
 >  
 > >>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:
 >  
 >     Jeffrey> Mark as the resident expert, can "restrict" be used to
 >     Jeffrey> tell the aliasing code that the return value from certain
 >     Jeffrey> functions can never alias anything else in the program?
 >  
 > I think the answer is "no, but that's OK".  For example, the following
 > code is legal C9X:
 >  
 >   int *restrict rp1;
 >  
 >   int *restrict f () {
 >     return rp1;
 >   }
 >  
 >   void f()
 >   {
 >     int *restrict rp2 = f();
 >   }
 >  
 > If GCC can't tell `f' from `malloc', then it must worry that the
 > storage returned by `malloc' is actually the same memory pointed to by
 > `rp1'.  But, C9X forbids using `rp1' to access memory while `rp2' is
 > in (dynamic) scope.
 >  
 > Making sense?  C9X committee members?
 > --
 > Mark Mitchell                   mark@codesourcery.com



Sorry, does that mean an attribute malloc would be useful or not? :-)

Does gcc support c9x restrict today?  (Even if it does, would there be
a -c89 mode, like -traditional in which case `restrict' wouldn't work
and so we would want an attribute malloc anyway?)

I went ahead and wrote something which seems to work.  Should I bother
submitting it?

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Re: Should we create an attribute malloc for supposed alias benefits?

[Mark Mitchell]

>>>>> "Kaveh" == Kaveh R Ghazi <ghazi@caip.rutgers.edu> writes:

    Kaveh> Sorry, does that mean an attribute malloc would be useful
    Kaveh> or not? :-)

I dunno.  If there are malloc-like functions in other languages that
do no have any way of saying `restrict', but do support attributes,
then it would be useful.

    Kaveh> Does gcc support c9x restrict today?  (Even if it does,
    Kaveh> would there be a -c89 mode, like -traditional in which case
    Kaveh> `restrict' wouldn't work and so we would want an attribute
    Kaveh> malloc anyway?)

We support __restrict__ in all modes.

    Kaveh> I went ahead and wrote something which seems to work.
    Kaveh> Should I bother submitting it?

I dunno.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Should we create an attribute malloc for supposed alias benefits?

[Mark Mitchell]

>>>>> "Kaveh" == Kaveh R Ghazi <ghazi@caip.rutgers.edu> writes:

    Kaveh> Sorry, does that mean an attribute malloc would be useful
    Kaveh> or not? :-)

I dunno.  If there are malloc-like functions in other languages that
do no have any way of saying `restrict', but do support attributes,
then it would be useful.

    Kaveh> Does gcc support c9x restrict today?  (Even if it does,
    Kaveh> would there be a -c89 mode, like -traditional in which case
    Kaveh> `restrict' wouldn't work and so we would want an attribute
    Kaveh> malloc anyway?)

We support __restrict__ in all modes.

    Kaveh> I went ahead and wrote something which seems to work.
    Kaveh> Should I bother submitting it?

I dunno.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Should we create an attribute malloc for supposed alias benefits?

[Kaveh R. Ghazi]

 > From: Mark Mitchell <mark@codesourcery.com>
 >  
 > >>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:
 >  
 >     Jeffrey> Mark as the resident expert, can "restrict" be used to
 >     Jeffrey> tell the aliasing code that the return value from certain
 >     Jeffrey> functions can never alias anything else in the program?
 >  
 > I think the answer is "no, but that's OK".  For example, the following
 > code is legal C9X:
 >  
 >   int *restrict rp1;
 >  
 >   int *restrict f () {
 >     return rp1;
 >   }
 >  
 >   void f()
 >   {
 >     int *restrict rp2 = f();
 >   }
 >  
 > If GCC can't tell `f' from `malloc', then it must worry that the
 > storage returned by `malloc' is actually the same memory pointed to by
 > `rp1'.  But, C9X forbids using `rp1' to access memory while `rp2' is
 > in (dynamic) scope.
 >  
 > Making sense?  C9X committee members?
 > --
 > Mark Mitchell                   mark@codesourcery.com



Sorry, does that mean an attribute malloc would be useful or not? :-)

Does gcc support c9x restrict today?  (Even if it does, would there be
a -c89 mode, like -traditional in which case `restrict' wouldn't work
and so we would want an attribute malloc anyway?)

I went ahead and wrote something which seems to work.  Should I bother
submitting it?

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Should we create an attribute malloc for supposed alias benefits?

[Kaveh R. Ghazi]

I noticed the following in calls.c:

 >       /* XXX should have "malloc" attribute on functions instead
 >          of recognizing them by name.  */
 >       else if (! strcmp (tname, "malloc")
 >                || ! strcmp (tname, "calloc")
 >                || ! strcmp (tname, "realloc")
 >                /* Note use of NAME rather than TNAME here.  These functions
 >                   are only reserved when preceded with __.  */
 >                || ! strcmp (name, "__vn")       /* mangled __builtin_vec_new */
 >                || ! strcmp (name, "__nw")       /* mangled __builtin_new */
 >                || ! strcmp (name, "__builtin_new")
 >                || ! strcmp (name, "__builtin_vec_new"))
 >         *is_malloc = 1;


	It looks like `is_malloc' is used later to decide that the
return value of a malloc-like function will never alias anything else.

Would it be useful to follow the comments and create an attribute
malloc?  Then we could declare things like xmalloc/xrealloc/xcalloc
with that attribute.  (We should probably add strdup/xstrdup to that
list.)  I don't know if the alias benefits would be worth it though.

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Re: Should we create an attribute malloc for supposed alias benefits?

[Jeffrey A Law]

  In message < 199909061940.PAA10973@caip.rutgers.edu >you write:
  > 	It looks like `is_malloc' is used later to decide that the
  > return value of a malloc-like function will never alias anything else.
Right.


  > Would it be useful to follow the comments and create an attribute
  > malloc? 
Yes.  It has been talked about before, but nobody ever got around to doing it.

  > Then we could declare things like xmalloc/xrealloc/xcalloc
  > with that attribute.  (We should probably add strdup/xstrdup to that
  > list.)  I don't know if the alias benefits would be worth it though.
More than alias benefits, it's cleaner than having gobs of magic function names
embedded in the compiler with no way to export the same functionality to users.

As long as we use embedded magic names with no exported interface to the
feature we'll be fighting users who want their magic name added to the list.


jeff

Re: Should we create an attribute malloc for supposed alias benefits?

[Robert Lipe]

Instead of adding more attributes, isn't this the very type of
functionality what C9X calls "restrict"?

>   > 	It looks like `is_malloc' is used later to decide that the
>   > return value of a malloc-like function will never alias anything else.
> Right.
> 
> 
>   > Would it be useful to follow the comments and create an attribute
>   > malloc? 
> Yes.  It has been talked about before, but nobody ever got around to doing it.

Re: Should we create an attribute malloc for supposed alias benefits?

[Jeffrey A Law]

  In message < 19990906170243.C11191@rjlhome.sco.com >you write:
  > Instead of adding more attributes, isn't this the very type of
  > functionality what C9X calls "restrict"?
I do not believe they are identical, but I'd have to go back and read the
various "restrict" threads to be sure.

Mark as the resident expert, can "restrict" be used to tell the aliasing code
that the return value from certain functions can never alias anything else
in the program?

jeff

Re: Should we create an attribute malloc for supposed alias benefits?

[Jeffrey A Law]

  In message < 19990906170243.C11191@rjlhome.sco.com >you write:
  > Instead of adding more attributes, isn't this the very type of
  > functionality what C9X calls "restrict"?
I do not believe they are identical, but I'd have to go back and read the
various "restrict" threads to be sure.

Mark as the resident expert, can "restrict" be used to tell the aliasing code
that the return value from certain functions can never alias anything else
in the program?

jeff

Re: Should we create an attribute malloc for supposed alias benefits?

[Robert Lipe]

Instead of adding more attributes, isn't this the very type of
functionality what C9X calls "restrict"?

>   > 	It looks like `is_malloc' is used later to decide that the
>   > return value of a malloc-like function will never alias anything else.
> Right.
> 
> 
>   > Would it be useful to follow the comments and create an attribute
>   > malloc? 
> Yes.  It has been talked about before, but nobody ever got around to doing it.

Re: Should we create an attribute malloc for supposed alias benefits?

[Jeffrey A Law]

  In message < 199909061940.PAA10973@caip.rutgers.edu >you write:
  > 	It looks like `is_malloc' is used later to decide that the
  > return value of a malloc-like function will never alias anything else.
Right.


  > Would it be useful to follow the comments and create an attribute
  > malloc? 
Yes.  It has been talked about before, but nobody ever got around to doing it.

  > Then we could declare things like xmalloc/xrealloc/xcalloc
  > with that attribute.  (We should probably add strdup/xstrdup to that
  > list.)  I don't know if the alias benefits would be worth it though.
More than alias benefits, it's cleaner than having gobs of magic function names
embedded in the compiler with no way to export the same functionality to users.

As long as we use embedded magic names with no exported interface to the
feature we'll be fighting users who want their magic name added to the list.


jeff

Should we create an attribute malloc for supposed alias benefits?

[Kaveh R. Ghazi]

I noticed the following in calls.c:

 >       /* XXX should have "malloc" attribute on functions instead
 >          of recognizing them by name.  */
 >       else if (! strcmp (tname, "malloc")
 >                || ! strcmp (tname, "calloc")
 >                || ! strcmp (tname, "realloc")
 >                /* Note use of NAME rather than TNAME here.  These functions
 >                   are only reserved when preceded with __.  */
 >                || ! strcmp (name, "__vn")       /* mangled __builtin_vec_new */
 >                || ! strcmp (name, "__nw")       /* mangled __builtin_new */
 >                || ! strcmp (name, "__builtin_new")
 >                || ! strcmp (name, "__builtin_vec_new"))
 >         *is_malloc = 1;


	It looks like `is_malloc' is used later to decide that the
return value of a malloc-like function will never alias anything else.

Would it be useful to follow the comments and create an attribute
malloc?  Then we could declare things like xmalloc/xrealloc/xcalloc
with that attribute.  (We should probably add strdup/xstrdup to that
list.)  I don't know if the alias benefits would be worth it though.

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions