Should we create an attribute malloc for supposed alias benefits?

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 aliasbenefits?

[Mark Mitchell]

>>>>> "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 can't quite figure it out.  I'll get back to you later today.

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

Re: Should we create an attribute malloc for supposed aliasbenefits?

[Mark Mitchell]

>>>>> "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 can't quite figure it out.  I'll get back to you later today.

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

Re: Should we create an attribute malloc for supposed aliasbenefits?

[Mark Mitchell]

>>>>> "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
CodeSourcery, LLC               http://www.codesourcery.com

Re: Should we create an attribute malloc for supposed aliasbenefits?

[Mark Mitchell]

>>>>> "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
CodeSourcery, LLC               http://www.codesourcery.com

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