> On Sun, Sep 29, 2002 at 05:27:31PM +0200, Andi Kleen wrote:
> > -extern pgd_t *pgd_alloc(struct mm_struct *);
> > +extern pgd_t *pgd_alloc(struct mm_struct *) malloc_function;
>
> Anz chance you could make that __malloc? That how the other
> atrributes in the kernel (e.g. __init/__exit) work.
No.
>
> > +/* Function allocates new memory and return cannot alias with anything */
> > +#define malloc_function __attribute__((malloc))
> > +/* Never inline */
> > +#define noinline __attribute__((noinline))
> > +#else
> > +#define malloc_function
> > +#define noinline
> > +#endif
>
> Dito for __noinline? And IMHO compiler.h is the better place for this.
Because I dislike all the __. It's just useless visual clutter and doesn't
follow the usual convention of prefixing only low level functions with this.
Also now that the kernel has given up on ANSI/POSIX name space cleanliness
it is double plus useless.
Same thing for __get_cpu_var for example. The __ is completely useless.
I will move it into linux/compiler.h to add some more clutter to include hell,
because it requires even more #include <linux/compiler.h>
> BTW, do you have any stats on the better optimization?
With this it sings twice as loud and dances twice and a half times as fast.
No, with gcc 3.2 it doesn't seem to make much difference.
More important is that will allow better optimization by gcc in the future.
In kernel land the gcc optimizer is already a bit crippled because of
the -fno-strict-aliasing use. This will hopefully help a bit.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/