Re: [lmi] gcc '-Wsuggest-attribute=' experiment

[Vadim Zeitlin]

On Fri, 5 Jun 2020 22:29:53 +0000 Greg Chicares <gchicares@sbcglobal.net> wrote:

GC> Vadim--I tried building lmi with all the '-Wsuggest-attribute=' flags.

 On a related note, I've been wanting, since quite some time, to run the
tool from https://github.com/trailofbits/constexpr-everything on lmi.
Adding constexpr everywhere where it can be added has much bigger benefits
than adding any attributes, as not only it can result in much faster code
(if it's really executed at compile-, rather than run-, time), but, most
importantly, it catches undefined behaviour at compile-time too.

GC> After excluding boost, I got only a handful of suggestions.

 Which is rather surprising, I'd really expect more... Could it be worth
checking this with -O3 rather than the usual -O2? I believe these checks
are supposed to work better with higher optimization levels.

GC> The question now is whether to do anything about this.
GC> 
GC> Examples: This MinGW library thing could be "const":
GC> 
GC>   extern "C" unsigned int _get_output_format(void) {return 1;}
GC> 
GC> and several functions like this could be "pure":
GC> 
GC>   bool begins_with(std::string const& s, std::string const& prefix)
GC>   {
GC>       return
GC>              (prefix.size() <= s.size())
GC>           && std::equal(prefix.begin(), prefix.end(), s.begin());
GC>   }
GC> 
GC> There's a proposal for "[[pure]]" here:
GC>   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0078r0.pdf
GC> but AFAIK the only thing we can do now is add an ugly, nonstandard,
GC> gcc-specific "__attribute__((const|pure))", which might save a few
GC> nanoseconds at the cost of portability. Am I missing anything?

 Well, the only tiny thing I can add is that we could use [[gnu::pure]]
attribute, which is supposed to be ignored by all the compilers that don't
support it, instead of __attribute__((pure)), which would have to be hidden
inside a macro to avoid breaking compilation with non-gcc/clang compilers.

 But globally you're absolutely right and [[pure]] doesn't exist even in
C++20, let alone C++17 that we currently use. So the best thing we could do
would be start using [[gnu::pure]] now and add a TODO note to replace it
with [[pure]] when it becomes standard. If it's just for a single function,
it's probably not worth it, however.

 Mostly, I'm still not sure how is it possible for a project of lmi size
(not huge, but not small neither) to have only 2 pure functions, something
really seems wrong here.

 Regards,
VZ

pgpFoa3aJ9fdZ.pgp
Description: PGP signature