[2.6 patch] remove the CONFIG_CC_ALIGN_* options

[2.6 patch] remove the CONFIG_CC_ALIGN_* options

[Adrian Bunk]

I don't see any use case for the CONFIG_CC_ALIGN_* options:
- they are only available if EMBEDDED
- people using EMBEDDED will most likely also enable 
  CC_OPTIMIZE_FOR_SIZE
- the default for -Os is to disable alignment

In case someone is doing performance comparisons and discovers that the
default settings gcc chooses aren't good, the only sane thing is to
discuss whether it makes sense to change this, not through offering 
options to change this locally.


Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

This patch was already sent on:
- 12 Feb 2006

 Makefile     |    7 -------
 init/Kconfig |   37 -------------------------------------
 2 files changed, 44 deletions(-)

--- linux-2.6.16-rc2-mm1-full/init/Kconfig.old	2006-02-12 15:30:08.000000000 +0100
+++ linux-2.6.16-rc2-mm1-full/init/Kconfig	2006-02-12 15:30:53.000000000 +0100
@@ -353,45 +353,8 @@
 	  to userspace as tmpfs if TMPFS is enabled. Disabling this
 	  option replaces shmem and tmpfs with the much simpler ramfs code,
 	  which may be appropriate on small systems without swap.
 
-config CC_ALIGN_FUNCTIONS
-	int "Function alignment" if EMBEDDED
-	default 0
-	help
-	  Align the start of functions to the next power-of-two greater than n,
-	  skipping up to n bytes.  For instance, 32 aligns functions
-	  to the next 32-byte boundary, but 24 would align to the next
-	  32-byte boundary only if this can be done by skipping 23 bytes or less.
-	  Zero means use compiler's default.
-
-config CC_ALIGN_LABELS
-	int "Label alignment" if EMBEDDED
-	default 0
-	help
-	  Align all branch targets to a power-of-two boundary, skipping
-	  up to n bytes like ALIGN_FUNCTIONS.  This option can easily
-	  make code slower, because it must insert dummy operations for
-	  when the branch target is reached in the usual flow of the code.
-	  Zero means use compiler's default.
-
-config CC_ALIGN_LOOPS
-	int "Loop alignment" if EMBEDDED
-	default 0
-	help
-	  Align loops to a power-of-two boundary, skipping up to n bytes.
-	  Zero means use compiler's default.
-
-config CC_ALIGN_JUMPS
-	int "Jump alignment" if EMBEDDED
-	default 0
-	help
-	  Align branch targets to a power-of-two boundary, for branch
-	  targets where the targets can only be reached by jumping,
-	  skipping up to n bytes like ALIGN_FUNCTIONS.  In this case,
-	  no dummy operations need be executed.
-	  Zero means use compiler's default.
-
 config SLAB
 	default y
 	bool "Use full SLAB allocator" if EMBEDDED
 	help
--- linux-2.6.16-rc2-mm1-full/Makefile.old	2006-02-12 15:30:59.000000000 +0100
+++ linux-2.6.16-rc2-mm1-full/Makefile	2006-02-12 15:31:24.000000000 +0100
@@ -473,15 +473,8 @@
 else
 CFLAGS		+= -O2
 endif
 
-#Add align options if CONFIG_CC_* is 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 $(call cc-option,-fno-optimize-sibling-calls,)
 else
 CFLAGS		+= -fomit-frame-pointer

Re: [2.6 patch] remove the CONFIG_CC_ALIGN_* options

[Sam Ravnborg]

On Mon, Feb 20, 2006 at 11:36:54PM +0100, Adrian Bunk wrote:
> I don't see any use case for the CONFIG_CC_ALIGN_* options:
> - they are only available if EMBEDDED
> - people using EMBEDDED will most likely also enable 
>   CC_OPTIMIZE_FOR_SIZE
> - the default for -Os is to disable alignment
> 
> In case someone is doing performance comparisons and discovers that the
> default settings gcc chooses aren't good, the only sane thing is to
> discuss whether it makes sense to change this, not through offering 
> options to change this locally.

I leave it to other to judge if this is wortwhile or not - I have no
numbers to back up either with or without.
It is though a nice cleaning effort in the Makefile.

But if we back-out this then cc-option-aling should go as well,
including description in Documentation/kbuild/makefiles.txt

	Sam

Re: [2.6 patch] remove the CONFIG_CC_ALIGN_* options

[Adrian Bunk]

On Tue, Feb 21, 2006 at 06:56:40PM +0100, Sam Ravnborg wrote:
> On Mon, Feb 20, 2006 at 11:36:54PM +0100, Adrian Bunk wrote:
> > I don't see any use case for the CONFIG_CC_ALIGN_* options:
> > - they are only available if EMBEDDED
> > - people using EMBEDDED will most likely also enable 
> >   CC_OPTIMIZE_FOR_SIZE
> > - the default for -Os is to disable alignment
> > 
> > In case someone is doing performance comparisons and discovers that the
> > default settings gcc chooses aren't good, the only sane thing is to
> > discuss whether it makes sense to change this, not through offering 
> > options to change this locally.
> 
> I leave it to other to judge if this is wortwhile or not - I have no
> numbers to back up either with or without.
> It is though a nice cleaning effort in the Makefile.
> 
> But if we back-out this then cc-option-aling should go as well,
> including description in Documentation/kbuild/makefiles.txt

My patch doesn't remove cc-option-align, and it's still used in 
arch/i386/Makefile.cpu.

The point of my patch is that there's no reason why a user should set 
different align options (if a developer wants to benchmark different 
align options, adding them to the CFLAGS in the Makefile is still 
trivial).

> 	Sam

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] remove the CONFIG_CC_ALIGN_* options

[Sam Ravnborg]

On Tue, Feb 21, 2006 at 07:44:07PM +0100, Adrian Bunk wrote:
> > 
> > But if we back-out this then cc-option-aling should go as well,
> > including description in Documentation/kbuild/makefiles.txt
> 
> My patch doesn't remove cc-option-align, and it's still used in 
> arch/i386/Makefile.cpu.
Right you are - thanks.

	Sam