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]
Other format: [Raw text]

Re: malloc attributes and realloc


On 3 Jan 2004, Gabriel Dos Reis wrote:

> Daniel Jacobowitz <drow@mvista.com> writes:
> 
> | On Sat, Jan 03, 2004 at 05:40:00AM +0100, Gabriel Dos Reis wrote:
> | > Robert Dewar <dewar@gnat.com> writes:
> | > 
> | > | Gabriel Dos Reis wrote:
> | > | 
> | > | > | can be safely optimized into
> | > | > |   *p = 'a';
> | > | > That transformation caanot be applied for pointers returned by
> | > | > realloc, in general.
> | > | 
> | > | Can you explain why?
> | > 
> | > The reason is obvious.
> | > 
> | > If p is a non-NULL pointer you get from a realloc, then it is
> | > guaranteed that the content of object previously pointed-to is still
> | > present at the start of new object.  Therefore, the compiler cannot,
> | > in general, replace the test *p != 'a' by true.
> | 
> | Gaby, you may have missed the original example:
> |   if (*p != 'a')
> |     *p == 'a';
> | 
> | Either it's already 'a' or it gets set to 'a'.  Depending on cache
> | behaviour and other issues already raised, this is a code-size win and
> | can be a performance win.  The only reason not to transform it is if
> | the object is in read-only storage, which either C or most useful C
> | compilers (I don't know which) allows.
> 
> Aha, thanks.  You're indeed correct.
> 
> -- Gaby

The only context I can think of in which this optmization would be invalid
is if p is a volatile pointer.

In this case, it could be pointing at some hardware register, and the act
of writing the hardware register may trigger some event which needs to be
performed conditionally.

Toshi



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