Memory access optimization

[rodneys]

Hi,

please take a look to this sample code:

class MyClass {
private:
static int length ;
public:
static void setLength(int newLength) ;
void do() ;
}

int MyClass::length ;

void MyClass::setLen gth(int newLength) {
length=newLengt h ;
}

void MyClass::do() {
for(int i=0;i<length;i+ +) {
// some simple floating point additions and multiplications ...
}
}

I expected that the compiler (Microsoft EVC 4 for ARM, full
optimization)
would optimize the for-loop of the method "do" to
register int t=length ;
for(int i=0;i<t;i++) {
...
}
But this does not happen. Instead, the generated machine code
refetches "length" in each iteration of the for-loop. Why?
Does the compiler "fear" that another thread could call "setLength"
while the for-loop runs? "length" is *not* declared volatile.

Is there a formal specification how long a compiler is allowed to cache
non-local variables in registers? For example, can code like
a = length ;
b = length ;
always be expected to be optimized to
register int t=length ;
a=t ;
b=t ;
?

rs

[Bo Persson]

"Bo Persson" <bo*@gmb.dk> skrev i meddelandet
news:42******** *****@individua l.net...

<ro*****@gmx.de > skrev i meddelandet
news:11******** *************@g 44g2000cwa.goog legroups.com...

Yes. The length is globally accessible through the public static
function setLength. To be able to cache the length, the compiler
must
first prove that no one is ever calling setLenght while the loop
runs.
As already discussed above, the specs don't force the compiler
to prove anything, do they?

Yes, they do. Using volatile prevents the compiler from keeping the
value in a register. Not using volatile doesn't automatically allow
caching. The compiler must first make sure that the value is not
updated any other way. If the variable is global, or accessible
through a public function, that is hard.

Consider this code:

int i;

void f(int& j)
{
for (i = 0; i < 10; i++)
j = i;
}

Ok, this was a bad example. Change the line to j = 1; to show the
problem with f(i).

int main()
{
int k;

f(k);
f(i);

}

What happens for f(k) ?
What happens for f(i) ?

Does that affect the optimizations possible for the function f()? It
sure does!
Bo Persson

[mlimber]

Bo Persson wrote:

<ro*****@gmx.de > skrev i meddelandet
news:11******** *************@g 44g2000cwa.goog legroups.com...

Yes. The length is globally accessible through the public static
function setLength. To be able to cache the length, the compiler
must
first prove that no one is ever calling setLenght while the loop
runs.

As already discussed above, the specs don't force the compiler
to prove anything, do they?

Yes, they do. Using volatile prevents the compiler from keeping the
value in a register.

[snip]

Actually, the meaning of volatile is compiler-specific, but in general
it means that the compiler should not do any fancy optimizations to the
data at hand. That could mean not caching a variable in a register even
though the code doesn't appear to change it. By using volatile, the
programmer is indicating that the value could change due to something
outside the program (e.g. another thread or process or a hardware
device). See TC++PL A.7.1.

Cheers! --M

[rodneys]

> Ok, this was a bad example. Change the line to j = 1; to show the

problem with f(i).

Thank you! I have eventually understood why the optimization did
not happen.
The for-loop contains code like

for(int i=0;i<length;i+ +) {
data[i]= ...some floating point math...
}

As in your example, it is possible (at least from the compiler's point
of view) that the assignment to "data[i]" overwrites "length". One
would need a very potent data flow analysis to prove the opposite.
/*
Please insert here some C/C++ bashing.
Topic: Why does C/C++ constantly forces me to do things that
are done by the compiler in other language?
*/

Ramin