This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Loop unrolling




On Tue, 2 Jun 1998, Gavin Romig-Koch wrote:

> Martin Knoblauch writes:
>  > > 	{
>  > > 	  volatile int i;
>  > > 	  for (i = 0; i < 10000; ++i);
>  > > 	}
>  > >
>  > 
>  >  Hmm. Does this prevent the loop from being deleted,
>  > or would it allow the compiler to just assign
>  > 9999 to "i"?
> 
> It should prevent the loop from being deleted.  My memory
> of the standard is vague, but basically, "volatile" tells
> the compiler that it actually must read and write the 
> memory location.  The compiler must assume that writing
> to the memory location has some unseen effect (say the
> memory location actually some device register),  and
> also that the memory locations value might change in
> an unseen way from the write to the following read.
> 
> This isn't the actuall wording, but it's something like:
> If the expressions between two sequence points contain
> one or more stores to a volatile memory location, then the
> running program must make at least one store to that
> memory location (storing the proper value).  Similarly
> for reads from a volatile memory location.

An access to an object through a volatile l-value constitutes a side effect. At
a sequence point, side effects must stabilize, so that the actual data objects
receive their correct values. Moreover, all evaluations that have side effects
must be performed.  However, the standard unfortunately leaves it up to the
implementation to define what constitutes access to an object declared
volatile. (See sections 5.1.2.3 and 6.5.3 of the ISO 9899:1990 standard).

An implementation could still optimize away a useless loop that iterates
over an auto variable that is not subsequently accessed, because auto
variables usually cannot have any properties that are useful in
connection with the volatile keyword.

In none of the GCC implementations does a hardware register appear in automatic
storage. Furthermore, the address of i was never taken, so there isn't any
reasonable way another process can have access to it. If its address
were taken, we might suspect that a pointer to i was communicated to
another thread---though a potentially difficult analysis could prove
otherwise.

I think that it's quite reasonable for a C implementation for a typical
platform to only apply special access semantics to volatile objects that are
accessed through pointers, are static, or are auto objects whose address was
taken (and hence which could not have been declared register).

In other words, a C compiler can do anything as long as a correct program
cannot detect a deviation from the requirements. A useless loop over an
auto variable whose location hasn't been disclosed to any other part of
the program in any legal way, may be replaced by a simple assignment
of the final value---and even that may be thrown away if there is no
subsequent use of that value.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]