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: [RFC] Marking C++ new operator as malloc?


On Sun, Sep 09, 2007 at 12:24:13PM -0700, Mark Mitchell wrote:
> The term "cannot alias" is not fully defined.  It could mean "cannot
> have the same value as any other pointer of the same type".  It could
> mean "cannot have the same value as any other pointer, when both
> pointers are cast to `void *'".  It could mean, a la "restrict", that
> "no store through an expression based on this pointer can modify the
> value read from via any expression based on any other pointer".
> 
> In the case of "malloc", and assuming that all of the machinery for
> malloc is hidden away in some piece of the program we're not talking
> about, all three definitions apply.  Each pointer returned by malloc is
> an island unto itself; there's no conforming way to get there except by
> using the pointer just returned.

The key point is that the mechanism is hidden away.  This might become
more of an issue with LTO, so the question is how to make such guarantees
make sense to an optimizer that can see the full program.

> For, operator new, the same is true -- but we're more often able to see
> the machinery for the allocator.  For example:
> 
> char pool[N];
> size_t next;
> 
> /* Never mind that the return memory isn't properly aligned here;
>    fixing the implementation is left to the reader.  */
> void *operator new(size_t s) {
>    void *p = pool + next;
>    next += s;
>    return p;
> }
> 
> bool f() {
>   char *c = new char;
>   return (c == pool);
> }
> 
> Now, I don't think we should allow the compiler to optimize the return
> statement in "f" to "return false"?  If operator new has attribute
> malloc, then it may in fact do so -- even though the value returned
> might be "pool" itself.

The issue seems to be that the mechanism is exposed.  The operator new
pointers don't alias each other (when used to store objects that fit
within the size argument), but they do have a relationship with "pool".
It seems that there needs to be some sort of protection boundary.
If there's no LTO, then it would suffice to treat the file implementing
operator new as a black-box module, perhaps exporting a "first_allocation"
function to do the c == pool check.

> This seems like a useful optimization to me, and I understand that it
> will work 99.99% of the time, and it's in the spirit of the standard --
> but how do we actually make it safe?  If the attribute only applied to
> other values returned from the same function, then it would be safe --
> but less useful.  Can we do better?

Maybe "pool", if exported, would have to be marked as aliasing the "new"
calls, possibly with some new attribute "malloc_implementation" or
something like that.  Working out the details would be tricky: calling
a malloc-attributed function might change storage marked
"malloc_implementation", and a return value might alias an implementation
value, but two calls would not alias each other.


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