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
Signed-off-by: Adrian Bunk <[email protected]>
---
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
On Sun, Feb 12, 2006 at 06:48:02PM +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
CONFIG_EMBEDDED should actually be spell CONFIG_ADVANCED. Not everyone
testing different alignments is building an embedded system targetted for
size. The option is just as useful in doing performance comparisons.
Besides, is it really a maintenence load?
-ben
On Sun, Feb 12, 2006 at 04:40:46PM -0500, Benjamin LaHaise wrote:
> On Sun, Feb 12, 2006 at 06:48:02PM +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
>
> CONFIG_EMBEDDED should actually be spell CONFIG_ADVANCED. Not everyone
We need both with CONFIG_EMBEDDED depending on CONFIG_ADVANCED (see my
other email).
> testing different alignments is building an embedded system targetted for
> size. The option is just as useful in doing performance comparisons.
> Besides, is it really a maintenence load?
It is not a maintenence load, but does it make sense to offer this in
any way to _users_?
gcc already sets this options with -Os/-O2.
We do already override the choice of gcc in some cpu specific cases.
If 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.
> -ben
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