This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC Common-Function-Attributes/const


[CC gcc list and Sandra]

Thanks for the suggestions.  I agree that the documentation
should make it possible to answer at least the basic questions
on your list.  We'll see about incorporating them.

In general, attributes that affect optimization are implemented
at a level where higher-level distinctions like those between
pointers and references, or between classes with user-defined
ctors vs PODs, are immaterial.  It's probably worth making that
clear in some preamble rather than for each individual attribute.

As far as requests for new attributes or features of existing
attributes I would suggest to raise those individually as
enhancements in Bugzilla where they can be appropriately
prioritized.

Martin

For context:
  https://gcc.gnu.org/ml/gcc/2018-11/msg00138.html

On 11/27/18 8:05 AM, cmdLP #CODE wrote:
Thank you for the reply.

*My suggestions for the documentation*
The documentation should inform if you can annotate c++ member functions with these attributes (pure, const). (It would make sence to interpret the whole object referenced by *this as a parameter)

The documentation should clarify how it handles structs/classes/unions and references. Does it threat references like pointers? Does it only allow PODs/trivial types to be returned, or does it invoke the copy constructor, when it is used again? (Eg.(assume PODs/trivial types are no problem) std::variant or std::optional with trivial types shouldn't be a problem, but std::variant and std::optional are not trivial).



There should be a way to express, that a returnvalue of a function never changes until another function is called. In my first e-mail I defined a class map, which has a getter and setter method; it is obvious, that calling get with the same key again yields the same value. It should be optimized to just one call to get. But the value might change, if you call set with the same key. The old returnvalue cannot be used anymore. After that  all calls to get can be merged again. This could improve the performance of libraries using associative arrays.

cmdLP


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]