Martin Sebor wrote on 06/26/2018 01:44 AM:
On 06/22/2018 12:32 AM, U.Mutlu wrote:
Hi,
it would be nice to have a mechanism to let the programmer give hints to
the compiler/optimizer.
Example:
for (size_t i = 1; i < vec.size(); ++i)
...
If the size of vec cannot change while in this code block, then one
better would do this instead:
{
const size_t vec_sz = vec.size();
for (size_t i = 1; i < vec_sz; ++i)
...
}
But, IMO it would be much better if one could just give a hint to the
compiler/optimizer instead:
#pragma hint const vec.size()
for (size_t i = 1; i < vec.size(); ++i)
...
Then the compiler/optimizer could cache the vec.size(), ie. fill a const
(register) variable just once and use that instead, like in the previous
manual version.
(The manual version has of course the disadvantage that user has to
define an additional variable and because of that, put the code in its
own scope...)
So, passing such hints to the compiler/optimizer is IMO a good general way.
Would be nice if the gcc developers would implement such a mechanism.
Technically: such a "#pragma hint ..." would apply just to the next line
of code, ie. automatically 'unhinting'.
Unfortunately, const alone isn't always sufficient because programs
can add constness to references and pointers and then cast it away,
and because internally GCC doesn't rely on constness as much as it
could.
Hmm. using dirty/illegal tricks?
More below.
For instance in this example, f() can cast the constness of its
argument away and change it. If the reference is bound to a non-
const object the program is valid:
void f (const std::vector<int>&);
void g (const std::vector<int> &v)
{
int n = v.size ();
f (v);
if (v.size () != n)
__builtin_abort ();
}
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?
But adding a #pragma isn't a solution to the problem. Both C
and to a slightly lesser extent also C++(*) have the necessary
mechanisms to let compilers emit efficient code. GCC just needs
to take better advantage of them.
I'm now using this helper struct for/in for-loops:
struct forVars // user can use this verbatim, or derive from this to add
more vars...
{
const size_t sz;
size_t i;
constexpr forVars(const size_t Asz, const size_t Astart = 0) noexcept :
sz(Asz), i(Astart) {}
~forVars() noexcept = default;
forVars(const forVars&) noexcept = delete;
forVars& operator=(const forVars&) noexcept = delete;
};
and in application, for example here starting at i=1:
for (forVars S(vec.size(), 1); S.i < S.sz; ++S.i) // S.sz is const
...
Martin
[*] C++ doesn't have the restrict keyword so it cannot express
all the same constraints as C can.
The alternative in g++ is __restrict__ :
https://en.wikipedia.org/wiki/Restrict
