This is the mail archive of the
mailing list for the GCC project.
Re: aligned attribute and the new operator (pr/15795)
- From: trevor_smigiel at playstation dot sony dot com
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Ian Lance Taylor <iant at google dot com>, Ulrich Weigand <Ulrich dot Weigand at de dot ibm dot com>, Russell_Olsen at playstation dot sony dot com
- Date: Mon, 18 Dec 2006 12:40:59 -0800
- Subject: Re: aligned attribute and the new operator (pr/15795)
- References: <20061010010443.GM24220@playstation.sony.com> <firstname.lastname@example.org> <20061012030808.GA5076@playstation.sony.com> <452E8371.email@example.com> <20061216024943.GW7501@playstation.sony.com> <4585F26C.firstname.lastname@example.org>
I can't add much to what has already been discussed in PR/15795 or the
previous thread on the gcc mailing list.
You are right, the user has the ability to solve this problem on their
own. The objective is to make it so they don't have to. Why can't we
make it just work?
There are cases, say with 3rd party libraries, where it is more
difficult for a user to solve the problem when they don't have access to
all of the code. The proposed extension won't solve this problem, but
will provide a consistent and documented way for it to work, and makes
it only a library writers problem, not the users problem.
In C, we have less ability to do anything, it is up to the user to call
memalign instead of malloc. But in C++ we do have the ability to make
it work for the new operator. So why not?
One example of usage on the PS3 is to use a 256-byte aligned class for
allocating DMA buffers. It just works because we've already extended
our gcc. In this case the user could have easily written their own
operator new, but never had to, and never needed to even think about it,
because we had already extended our gcc. Changing malloc to always
return 256-byte aligned memory would not have been a good idea in the
limited memory of an SPU.
I think we have the ability to make it work for C++ and think telling
the users it is their problem is unnecessary. Valid, just unnecessary.
So the strongest argument for doing it, is just to make life easier for
the end user. I think that is a good reason.
* Mark Mitchell <email@example.com> [2006-12-18 01:44]:
> firstname.lastname@example.org wrote:
> > I've attached a preliminary patch for the sake of discussion and to
> > see if this approach is ok.
> > Briefly, the idea is to introduce four new special functions,
> > void* __align_new (std::size_t size, std::size_t align);
> > void* __align_new_a (std::size_t size, std::size_t align);
> > void __align_delete (void* ptr, std::size_t align);
> > void __align_delete_a (void* ptr, std::size_t align);
> > When a type being operated on with new or delete has alignment greater
> > than some target defined value the front end searches for one of the
> > special functions and replaces the call.
> I don't understand the motivation for this patch.
> First, from C99 7.20.3, malloc is required to return storage that is
> aligned sufficiently for any type that fits in the size requested:
> The pointer returned if the allocation succeeds is suitably aligned so
> that it may be assigned to a pointer to any type of object and then used
> to access such an object or an array of such objects in the space
> allocated (until the space is explicitly deallocated).
> So, you're apparently stuck with a non-conforming implementation of
> malloc? Why can't it just be fixed?
> Second, you could replace the default "operator new" and "operator
> delete" to call a more-aligned malloc, e.g., posix_memalign.
> The only thing I can think of is that you have small type with very
> strong alignment requirements (e.g., an 8-byte type with a 256-byte
> alignment requirements) and so you want to be able to allocate most 8
> byte types without this alignment requirement? Is that the situation?
> Since we're in a C++ context, I would think the right solution is to
> create a class wrapper for the type with its own class-specific new and
> delete operators?
> Mark Mitchell
> (650) 331-3385 x713