[PATCH] malloc.c fix for MALLOC_ALIGN_MASK tests.

[Peter Bergner]

On Thu, 2005-09-15 at 12:33 -0700, Ulrich Drepper wrote:
> Peter Bergner wrote:
> > I'm curious, how does the patch make the checks more expensive?
> 
> Just run it through the compiler, especially on x86.

This is my last post on this subject.  However, out of curiosity,
I did compile the code with and without the patch for both ppc
and x86.  Looking at the ppc dissassembly, there is no performance
difference between the patched and unpatched code.  For x86, there
are a few places where the code is slightly worse, but just as many
places where the code looks slightly better.  To me (admittedly, I'm
not an x86 assembly expert), the code generation changes on x86 look
like a wash.  I have attached the x86 and ppc objdump diffs in case
you're interested too.


> > than testing for a
> > particular architecture in case another arch or user attempts to
> > use a larger MALLOC_ALIGNMENT?
> 
> Nobody should do such a stupid thing.  It creates binary
> incompatibilities.  If you need more alignment, use posix_memalign.

I admit I didn't explain the reasoning behind our change to a larger
MALLOC_ALIGNMENT rather than just using posix_memalign.  We have a
Linux system that is used for running FP intensive applications on a
ppc based processor that has severe alignment restrictions whenever
we do a load/store from the FP unit.  Essentially, any storage we may
load/store from/to by the FP unit (including malloc'd storage) needs
to be 16 byte aligned or we'll take an alignment exception.  You are
correct that for explicit allocations, we can use posix_memalign(),
but for implicit memory allocations (eg, C++ constructors), we can't
easily force them to use posix_memalign rather than malloc.  Also, we
didn't really want to go through all the source packages that make up
a Linux system and modify their source's to use posix_memalign().
Therefore, we decided it would be easier to modify MALLOC_ALIGNMENT.
And yes, we also required GCC changes as well.  To get around binary
incompatibilities, we only allow running binaries compiled with our
modified toolchain on this system.

Yeah, yeah, I know what you're thoughts are about the system.  I'll just
say it is what it is.  I didn't get to design or choose the hardware we
used.  All I could do was make it work given the circumstances.

Peter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: malloc-ppc.diff
Type: text/x-patch
Size: 10218 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20050919/be807840/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: malloc-x86.diff
Type: text/x-patch
Size: 146107 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20050919/be807840/attachment-0001.bin>