linux-kernel - Re: Status of CONFIG_FORCED

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: <adawsyy5azc.fsf@cisco.com>
Date:	Thu, 24 May 2007 11:32:07 -0700
From:	Roland Dreier <rdreier@...co.com>
To:	Adrian Bunk <bunk@...sta.de>
Cc:	Rob Landley <rob@...dley.net>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Status of CONFIG_FORCED_INLINING?

 > The problem is that inline functions in headers are intended to be 
 > called from different C files.
 > 
 > gcc might not inline it in the C files where it is called more than 
 > once.
 > 
 > But it will always inline it if it's called only once.
 > 
 > One of both will be suboptimal, but from gcc's perspective it was 
 > optimal.

Yes, we could probably get huge benefits from --combine and/or
-fwhole-program to let gcc see more than one file at a time.

But I still don't see the issue with having gcc do the best it can on
each file it compiles.  If you force the inlining, then that means
that on files where not inlining was better, you've forced gcc to
generate worse code.  (I don't see how not inlining could be locally
better on a single file but globally worse, even though it generated
better code on each compiled file)
-
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/