Re: Need volunteer for #61780 - G_GNUC_MALLOC()
- From: degger fhm edu
- To: otaylor redhat com
- Cc: gtk-devel-list gnome org, matthiasc poet de
- Subject: Re: Need volunteer for #61780 - G_GNUC_MALLOC()
- Date: Mon, 17 Dec 2001 01:15:06 +0100 (CET)
On 6 Dec, Owen Taylor wrote:
> that adds gcc function attributes to various GLib functions is
> blocking on one part -- we need someone to try applying the patch and
> compiling some tests with and without the G_GNUC_MALLOC() part and see
> if it make any difference to code generation. (Preferably with a
> recentish GCC, such as 2.96, 3.0 or 3.1)
I just tried it on powerpc-gnu-linux with a gcc from 4 hours ago
(pre3.1) with glibc 2.2.4 and I can tell that it makes a difference
in code generation; not much but in general enough to get faster
und slightly smaller. And - I don't exactly know why as of yet -
it seems to affect the inlining rules so we get a higher degree
of inlining which didn't seem like a bad choice in the cases I've
seen.
The patch is highly broken though as it did neither apply cleanly
nor compile after the merging because the compiler wants to have
the __attribute__((malloc)) before the return type and not right before
the function body for the C-sources. I also haven't checked for
semantic correctness so far.
It would be nice to have some sort of testapplication that can be easily
benchmarked to get some performance figures but I cannot imagine a good
testcase for this particular case.
The general idea is IMHO good because more information will help the
compiler to generate better code in any case and thus it should be
applied where possible.
I can repeat the same round for i386-gnu-linux if wanted though I'm
not quite sure which information it is you'd like to have attached to
the bugreport because I don't think assembly diffs would make people
happy or help really much.
--
Servus,
Daniel
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]