linux-kernel - Re: [RFC: 2.6 patch] add -fno-tree-scev-cprop to KBUILD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4738CEBB.8000501@t-online.de>
Date:	Mon, 12 Nov 2007 23:07:55 +0100
From:	Bernd Schmidt <bernds_cb1@...nline.de>
To:	Adrian Bunk <bunk@...nel.org>
CC:	Sam Ravnborg <sam@...nborg.org>, linux-kernel@...r.kernel.org
Subject: Re: [RFC: 2.6 patch] add -fno-tree-scev-cprop to KBUILD_CFLAGS

Adrian Bunk wrote:
> It can be a performance regression, but there are also cases where it 
> can improve performance. If gcc produces lower performance code that
> would be a bug in gcc that should be reported, but using a division is 
> not generally wrong.
> 
> A more clearer example might be:
> 
> <--  snip  -->
> 
> void foo(u64 ns)
> {
> 	if (ns < 10000)
> 		return;
> 
> 	while(ns >= 3) {
> 		ns -= 3;
> #ifdef DEBUG
> 		bar(ns);
> #endif
> 	}
> }
> 
> <--  snip  -->
> 
> With DEBUG not defined you can hardly argue gcc should be fixed to not 
> use a division for performance reasons.

Absent any clear information about the possible values of ns, IMO this
is a case where the compiler should just assume that the programmer
knows best whether to use a loop or a division.  Principle of least
surprise, and all that...


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/