From: Pavel Machek <pavel@ucw.cz>
To: Matthew Wilcox <willy@debian.org>
Cc: gcc@gcc.gnu.org
Subject: Re: [ACPI] Why does gcc suck at switch()?
Date: Sun, 05 Oct 2003 16:53:00 -0000 [thread overview]
Message-ID: <20031005165237.GB753@elf.ucw.cz> (raw)
In-Reply-To: <20031003145614.GP24824@parcelfarce.linux.theplanet.co.uk>
Hi!
> Why does gcc generate worse code for switch() statements than for
> multiple-if?
>
> $ gcc --version
> gcc (GCC) 3.3.2 20030908 (Debian prerelease)
>
> I would expect a compiler to produce the same code for these cases.
> Instead, switch is worse than the multiple-if:
>
> - switch (event) {
> - case ACPI_THERMAL_NOTIFY_TEMPERATURE:
> + if (event == ACPI_THERMAL_NOTIFY_TEMPERATURE) {
> acpi_thermal_check(tz);
> - break;
> - case ACPI_THERMAL_NOTIFY_THRESHOLDS:
> + } else if (event == ACPI_THERMAL_NOTIFY_THRESHOLDS) {
> acpi_thermal_get_trip_points(tz);
> acpi_thermal_check(tz);
> acpi_bus_generate_event(device, event, 0);
> - break;
> - case ACPI_THERMAL_NOTIFY_DEVICES:
> + } else if (event == ACPI_THERMAL_NOTIFY_DEVICES) {
> if (tz->flags.devices)
> acpi_thermal_get_devices(tz);
> acpi_bus_generate_event(device, event, 0);
> - break;
> - default:
> + } else {
> ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> "Unsupported event [0x%x]\n", event));
> - break;
> }
>
> $ size *.o
> text data bss dec hex filename
> 5996 704 16 6716 1a3c thermal-multiple-if.o
> 6005 704 16 6725 1a45 thermal-switch.o
>
> Here's the asm diff between the two versions:
>
> - cmpl $129, %esi
> - je .L597
> - cmpl $129, %esi
> - ja .L602
> - addl $-128, %esi
> - je .L596
> - jmp .L592
> -.L602:
> - cmpl $130, %esi
> - je .L598
> - jmp .L592
> -.L596:
> + cmpl $128, %esi
> + jne .L595
> ...
> -.L597:
> +.L595:
> + cmpl $129, %esi
> + jne .L597
> ...
> -.L598:
> +.L597:
> + cmpl $130, %esi
> + jne .L592
>
> The other diffs are just label numbers changing. Given that gcc was
> instructed to optimise for space (full command line:
>
> gcc -Wp,-MD,drivers/acpi/.thermal.o.d -nostdinc -iwithprefix include \
> -D__KERNEL__ -Iinclude -D__KERNEL__ -Iinclude -Wall \
> -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing \
> -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 \
> -Iinclude/asm-i386/mach-default -fomit-frame-pointer -Os \
> -DKBUILD_BASENAME=thermal -DKBUILD_MODNAME=thermal -c \
> -o drivers/acpi/thermal.o drivers/acpi/thermal.c
>
> I think it should choose the more space-efficient approach.
Okay, but please don't change kernel code to workaround compiler
problem. This should probably be sent to gcc mailing list... Ahha, it
is. Not sure if it needs to be cc-ed to acpi at all.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
next prev parent reply other threads:[~2003-10-05 16:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-03 14:56 Matthew Wilcox
2003-10-05 16:53 ` Pavel Machek [this message]
2003-10-12 5:49 ` law
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20031005165237.GB753@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=gcc@gcc.gnu.org \
--cc=willy@debian.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).