Martin Sebor wrote on 06/26/2018 05:16 AM:
When the reference passed to f() is bound to an object that's
defined const GCC could assume that the call to f() doesn't
change it and emit better code but, unfortunately, it does not.
As a result, even though GCC could avoid the test below, it
emits it.
void g (void)
{
const std::vector<int> v;
int n = v.size ();
f (v);
if (v.size () != n)
__builtin_abort ();
}
GCC does eliminate such tests in the simple cases when v is
a fundamental type like int, but not when it's a struct (even
a trivial one containing just an int).
Hmm. if that is really true then I would be negatively surprised.
I just tested it with the the latest g++ (v9) and it gives a compile
error
if one tries to modify the vector inside f().
And that is the expected behaviour, so I wonder which compiler &
version you
mean?
Ok, you mean this:
if (v.size () != n)
__builtin_abort ();
But the compliler cannot know that size() returns a vector-internal value,
ie. it could also be an external value, therefore it can't optimize it
away, IMO.
Jonathan already made it clear earlier that GCC can determine
that the return value of vector::size() doesn't change between
successive calls to the function because it's is trivially
inline and doesn't modify any data, and therefore can
eliminate all but the first call.
For a reduced test case showing the missing optimization see
bug 86318.
Ok, I see, with a deep-analysis the compiler/optimizer can determine
whether the member func, here size() const, is returning
a non-changing value, that is
a) either an object-intern variable
(in this case regardless of the constness of the object itself
as a whole as it was passed to f() as a const reference,
so v can't change in f() and therefore between the two v.size() calls)),
b) a true const variable or value (intern or extern), or
c) a calculated value (intern or extern) that is always the same,
then the said optimization afterwards can indeed be made, yes, true.
It's all about the quality/depthness of the analysis.
But in the general case (ie. any func), the _calculated_ return value cases
are IMO the hardest to analyse correctly.
Therefore, I think the power-user can and should help the compiler/optimizer
with some new function attributes/hints (and maybe also variable
attributes/hints), to keep the gcc guesswork and the codebase light,
and still be flexible and powerful.
