use of memset and optimization

Ken Raeburn raeburn at MIT.EDU
Fri Nov 8 15:22:01 EST 2002


Bill Sommerfeld <sommerfeld at orchard.arlington.ma.us> writes:

> I think a good case can be made that even a memset of an auto volatile
> array can be optimized away if the compiler can prove through
> interprocedural or intermodule analysis that the address of the array
> never escapes.

"At sequence points, volatile objects are stable in the sense that
previous evaluations are complete and subsequent evaluationts have not
yet occurred."  I think that rules out this optimization.

> You'd have to "pierce the abstraction barrier" to notice otherwise and
> therefore the optimization is "safe".

Isn't breaking that barrier largely what "volatile" is for?  For
example, global volatile variables mapped to device registers can't
have multiple consecutive reads collapsed into one, but in a simple
abstract C machine there's no way such a variable could be changed
(assuming no signal handlers change it, etc).

> Remember, the compiler owns the stack.  

Any more than static-storage or heap variables?

> The compiler folks will get very bent out of shape if you say that
> you've set things up so that auto volatile array will land on top of a
> virtual mapping in I/O space for a particular device and this it's
> always worked in past releases of the compiler....

The compiler (and compiler writers) controls the memory allocation in
that case, so they should get upset at you if you insist that you
should always get the same address or something.  But that's not the
case here.

And if you set up the mapping of the device registers based on the
address of the array instead, that's something they wouldn't have
quite so much ground to complain about.

> (yes, that's right, a C compiler determined when it was safe to turn
> an array-of-structures into a structure-of-arrays to improve memory
> bandwidth for an inner loop which only looked at a couple of the
> structure fields..)

Woo.  I'm impressed.  Especially since it's for C, and not some
language with serious type-safety facilities.  The restrictions are
kind of unfortunate, though.



More information about the krbdev mailing list