linux-kernel - Re: "eliminate warn_on_slowpath()" change causes many gcc-3.2.3 warnings

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]

Date:	Sun, 18 Jan 2009 11:01:44 +1100 (EST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"H. Peter Anvin" <hpa@...or.com>
cc:	Kyle McMartin <kyle@...radead.org>, Ingo Molnar <mingo@...e.hu>,
	Mikael Pettersson <mikpe@...uu.se>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: "eliminate warn_on_slowpath()" change causes many gcc-3.2.3
 warnings

On Sat, 17 Jan 2009, H. Peter Anvin wrote:
> 
> At least on x86, the two ops should be the same cost?

Not with the code Kyle had, which forces a memory load.

But yes, with a constant address, it at least comes close. But with a 
small explicit constant value, the compiler can often do even better. For 
example, you can generate a 64-bit -1 in many ways, while a 64-bit random 
address is much more work to generate.

Of course, I don't know how much gcc takes advantage of this. Maybe it 
always just generates a silly "movq" rather than being smarter about it 
(eg "orl $-1,reg" can do it in four bytes, I think, because you can use a 
single-byte constant).

Of course, zero is even easier to generate, so NULL is the best constant 
of all, but generally small integers are more amenable to optimization 
than generic addresses. They're also generally easier to test for.

		Linus
--
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/