Resend.
With all alignment options set to 1 (minimum alignment),
I've got 5% smaller vmlinux compared to one built with
default code alignment.
Rediffed against 2.6.9-rc3.
Please apply.
--
vda
Denis Vlasenko <[email protected]> wrote:
>
> With all alignment options set to 1 (minimum alignment),
> I've got 5% smaller vmlinux compared to one built with
> default code alignment.
>
Sam, can you process this one?
>
>
> +GCC_VERSION = $(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-version.sh $(CC))
It bugs me that we're evaluating the same thing down in arch/i386/Makefile.
Perhaps we should evaluate GCC_VERSION once only, as some top-level kbuild
thing. So everyone can assume that it's present and correct?
Denis Vlasenko wrote:
> Resend.
>
> With all alignment options set to 1 (minimum alignment),
> I've got 5% smaller vmlinux compared to one built with
> default code alignment.
It would be interesting to know if this is better WRT cache usage than
alignment which ensures that loops fit within the minimum number of
cache lines. That's not quite the same thing as starting on a cache line
in all cases.
This may be of interest to embedded builds.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Fri, Oct 01, 2004 at 03:17:51PM -0700, Andrew Morton wrote:
> Denis Vlasenko <[email protected]> wrote:
> >
> > With all alignment options set to 1 (minimum alignment),
> > I've got 5% smaller vmlinux compared to one built with
> > default code alignment.
> >
>
> Sam, can you process this one?
I will do so in a week or so.
Travelling (and busy) these days.
Sam
On Fri, 1 Oct 2004 15:17:51 -0700,
Andrew Morton <[email protected]> wrote:
>Denis Vlasenko <[email protected]> wrote:
>>
>> With all alignment options set to 1 (minimum alignment),
>> I've got 5% smaller vmlinux compared to one built with
>> default code alignment.
>>
>
>Sam, can you process this one?
>
>>
>>
>> +GCC_VERSION = $(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-version.sh $(CC))
>
>It bugs me that we're evaluating the same thing down in arch/i386/Makefile.
> Perhaps we should evaluate GCC_VERSION once only, as some top-level kbuild
>thing. So everyone can assume that it's present and correct?
Using '=' is wrong here, it will evaluate the complete expression every
time GCC_VERSION is tested. It should be ':='. The only time '='
should be used in a Makefile is when delayed evaluation is really
required, e.g. for strings that are the target of $(call).
Denis Vlasenko <[email protected]> writes:
> Resend.
>
> With all alignment options set to 1 (minimum alignment),
> I've got 5% smaller vmlinux compared to one built with
> default code alignment.
>
> Rediffed against 2.6.9-rc3.
> Please apply.
I agree with the basic idea (the big alignments also always annoy
me when I look at disassembly), but I think your CONFIG options
are far too complicated. I don't think anybody will go as far as
to tune loops vs function calls.
I would just do a single CONFIG_NO_ALIGNMENTS that sets everything to
1, that should be enough.
-Andi
On Friday 08 October 2004 12:20, Andi Kleen wrote:
> Denis Vlasenko <[email protected]> writes:
> > Resend.
> >
> > With all alignment options set to 1 (minimum alignment),
> > I've got 5% smaller vmlinux compared to one built with
> > default code alignment.
> >
> > Rediffed against 2.6.9-rc3.
> > Please apply.
>
> I agree with the basic idea (the big alignments also always annoy
> me when I look at disassembly), but I think your CONFIG options
> are far too complicated. I don't think anybody will go as far as
> to tune loops vs function calls.
>
> I would just do a single CONFIG_NO_ALIGNMENTS that sets everything to
> 1, that should be enough.
For me, yes, but there are people which are slightly less obsessed
with code size than me.
They might want to say "try to align to 16 bytes if
it costs less than 5 bytes" etc.
Also bencmarking people may do little research on real usefulness of
various kinds of alignment.
--
vda
On Fri, 8 Oct 2004, Denis Vlasenko wrote:
> On Friday 08 October 2004 12:20, Andi Kleen wrote:
>> Denis Vlasenko <[email protected]> writes:
>>> Resend.
>>>
>>> With all alignment options set to 1 (minimum alignment),
>>> I've got 5% smaller vmlinux compared to one built with
>>> default code alignment.
>>>
>>> Rediffed against 2.6.9-rc3.
>>> Please apply.
>>
>> I agree with the basic idea (the big alignments also always annoy
>> me when I look at disassembly), but I think your CONFIG options
>> are far too complicated. I don't think anybody will go as far as
>> to tune loops vs function calls.
>>
>> I would just do a single CONFIG_NO_ALIGNMENTS that sets everything to
>> 1, that should be enough.
>
> For me, yes, but there are people which are slightly less obsessed
> with code size than me.
>
> They might want to say "try to align to 16 bytes if
> it costs less than 5 bytes" etc.
>
> Also bencmarking people may do little research on real usefulness of
> various kinds of alignment.
I think that removing aligns completly will be very bad. I am Gentoo user
and I set my user space CFLAGS for all system to -falign-loops
-fno-align-<everything else>. I did not tested it in depth, but my simple
tests show that unaligning loops is a very bad idea. Unaligning functions
is safer since small and fast functions should be always inlined.
Thanks,
Grzegorz Kulewski
On Fri, Oct 08, 2004 at 05:10:58PM +0000, Denis Vlasenko wrote:
> On Friday 08 October 2004 12:20, Andi Kleen wrote:
> > Denis Vlasenko <[email protected]> writes:
> > > Resend.
> > >
> > > With all alignment options set to 1 (minimum alignment),
> > > I've got 5% smaller vmlinux compared to one built with
> > > default code alignment.
> > >
> > > Rediffed against 2.6.9-rc3.
> > > Please apply.
> >
> > I agree with the basic idea (the big alignments also always annoy
> > me when I look at disassembly), but I think your CONFIG options
> > are far too complicated. I don't think anybody will go as far as
> > to tune loops vs function calls.
> >
> > I would just do a single CONFIG_NO_ALIGNMENTS that sets everything to
> > 1, that should be enough.
>
> For me, yes, but there are people which are slightly less obsessed
> with code size than me.
>
> They might want to say "try to align to 16 bytes if
> it costs less than 5 bytes" etc.
If they want to go down to that low level they can as well edit
the Makefiles. But we already have far too many configs and
adding new ones for obscure compiler options is not a good idea.
Also we don't normally add stuff "just in case", but only when
people actually use it.
-Andi
On Friday 08 October 2004 17:30, Grzegorz Kulewski wrote:
> > Also bencmarking people may do little research on real usefulness of
> > various kinds of alignment.
>
> I think that removing aligns completly will be very bad. I am Gentoo user
> and I set my user space CFLAGS for all system to -falign-loops
> -fno-align-<everything else>. I did not tested it in depth, but my simple
> tests show that unaligning loops is a very bad idea. Unaligning functions
That depends on how often that loop runs. 90% of code runs only
10% of time. I think ultimately we want to mark other 10% of code with:
int __hotpath often_called_func()
{
...
}
Rest of code is to be optimized for size.
> is safer since small and fast functions should be always inlined.
Concept of alignment does not apply to inlined functions at all.
--
vda
> > > I would just do a single CONFIG_NO_ALIGNMENTS that sets everything to
> > > 1, that should be enough.
> >
> > For me, yes, but there are people which are slightly less obsessed
> > with code size than me.
> >
> > They might want to say "try to align to 16 bytes if
> > it costs less than 5 bytes" etc.
>
> If they want to go down to that low level they can as well edit
> the Makefiles. But we already have far too many configs and
> adding new ones for obscure compiler options is not a good idea.
>
> Also we don't normally add stuff "just in case", but only when
> people actually use it.
I have a suspicion that if I had submitted CONFIG_NO_ALIGNMENTS
patch instead, there would be comments from another crowd,
about it being too coarse.
Look at the post of Grzegorz Kulewski.
Anyway, I don't have strong preference. I just want to be at least
able to disable code alignment completely.
--
vda
On Fri, 8 Oct 2004, Denis Vlasenko wrote:
> On Friday 08 October 2004 17:30, Grzegorz Kulewski wrote:
>>> Also bencmarking people may do little research on real usefulness of
>>> various kinds of alignment.
>>
>> I think that removing aligns completly will be very bad. I am Gentoo user
>> and I set my user space CFLAGS for all system to -falign-loops
>> -fno-align-<everything else>. I did not tested it in depth, but my simple
>> tests show that unaligning loops is a very bad idea. Unaligning functions
>
> That depends on how often that loop runs. 90% of code runs only
> 10% of time. I think ultimately we want to mark other 10% of code with:
Well, loops should probably always be aligned because aligning them will
not make the code significantly larger (I think, I did not mensure it),
but it will make the code significantly faster, and more friendly to
processor's cache.
>> is safer since small and fast functions should be always inlined.
>
> Concept of alignment does not apply to inlined functions at all.
That is my point. It is safe not to align functions because fast and often
called ones will be inlined and will not be slowed down by lack of
alignment.
Thanks,
Grzegorz Kulewski
On Fri, Oct 01, 2004 at 03:17:51PM -0700, Andrew Morton wrote:
> Denis Vlasenko <[email protected]> wrote:
> >
> > With all alignment options set to 1 (minimum alignment),
> > I've got 5% smaller vmlinux compared to one built with
> > default code alignment.
> >
>
> Sam, can you process this one?
>
> >
> >
> > +GCC_VERSION = $(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-version.sh $(CC))
>
> It bugs me that we're evaluating the same thing down in arch/i386/Makefile.
> Perhaps we should evaluate GCC_VERSION once only, as some top-level kbuild
> thing. So everyone can assume that it's present and correct?
Started looking into this.
gcc does not document what happens if -falign-functions=x is specified more than
once. It works but I have not checked the effect.
It will occur for some CPU's
Sam
Current patch to top-level Makefile looks like this.
===== Makefile 1.542 vs edited =====
--- 1.542/Makefile 2004-10-17 02:00:48 +02:00
+++ edited/Makefile 2004-10-17 02:29:56 +02:00
@@ -295,6 +295,11 @@
cc-option-yn = $(shell if $(CC) $(CFLAGS) $(1) -S -o /dev/null -xc /dev/null \
> /dev/null 2>&1; then echo "y"; else echo "n"; fi;)
+# cc-option-align
+# Prefix align with either -falign or -malign
+cc-option-align = $(subst -functions=0,,\
+ $(call cc-option,-falign-functions=0,-malign-functions=0))
+
# cc-version
# Usage gcc-ver := $(call cc-version $(CC))
cc-version = $(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-version.sh \
@@ -497,6 +502,13 @@
else
CFLAGS += -O2
endif
+
+#Add aling options in CONFIG_CC_ not equal to 0
+add-align = $(if $(filter-out 0,$($(1))),$(cc-option-align)$(2)=$($(1)))
+CFLAGS += $(call add-align,CONFIG_CC_ALIGN_FUNCTIONS,-functions)
+CFLAGS += $(call add-align,CONFIG_CC_ALIGN_LABELS,-labels)
+CFLAGS += $(call add-align,CONFIG_CC_ALIGN_LOOPS,-loops)
+CFLAGS += $(call add-align,CONFIG_CC_ALIGN_JUMPS,-jumps)
ifdef CONFIG_FRAME_POINTER
CFLAGS += -fno-omit-frame-pointer