Re: optimisation question

[James E Wilson <wilson at specifixinc dot com>]

Remy X.O. Martin wrote:
> 2) statements like a= c= d; are not (necessarily) optimal

This is true, though it is likely rare that it will be a problem.

The issue here is that a=c=d is equivalent to a=(c=d), note the 
parentheses.  This means that if c=d requires a conversion, then the 
result of a depends on the result of that conversion, which results in a 
series of dependent operations.  On the other hand, if you write c=d;a=d
then the conversions are independent and can be performed in parallel, 
or alternatively, you may require fewer conversions.

I've attached an example.  The tmp.c file uses a group of dependent 
assignments.  The tmp2.c file uses independent assignments.  If I 
compile this for IA-64 with -O2 -S, the tmp.c file requires 12 stop bits 
and 14 bundles, and the tmp2.c file requires 6 stop bits and 11 bundles. 
 I didn't try computing timing, but I'd expect the tmp2.c version to be 
noticably faster than the tmp.c version.  You should get similar results 
for other targets with multiple pipelined function units.

I should point out that my two example files are computing different 
things, but in most cases this difference is not significant to and/or 
intended by the programmer.

And, oh, about the dest->array thing, the answer from Chris Jefferson 
was correct.  array[i] is a single dereference, and can be easily 
handled by the compiler, but dest->array[i] requires two dereferences 
and it is so much harder to handle aliasing issues in this case that 
compilers like gcc may not be able to optimize it fully.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
int
sub (int i)
{
  float f;
  char c;
  double d;

  f = c = d = i;
  return sub2 (f, c, d);
}

int
sub (int i)
{
  float f;
  char c;
  double d;

  d = i;
  c = i;
  f = i;
  return sub2 (f, c, d);
}