From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH 0/2] Improvements with noreturn Date: Mon, 25 Nov 2013 14:46:38 +0000 Message-ID: <529362CE.4020208@eu.citrix.com> References: <1385375142-8216-1-git-send-email-andrew.cooper3@citrix.com> <52935861.40704@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <52935861.40704@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: Xen-devel List-Id: xen-devel@lists.xenproject.org On 11/25/2013 02:02 PM, Andrew Cooper wrote: > On 25/11/13 11:47, George Dunlap wrote: >> On Mon, Nov 25, 2013 at 10:25 AM, Andrew Cooper >> wrote: >>> Make better use of noreturn. It allows optimising compilers to produce more >>> efficient code. >>> >>> George: >>> I request that this is included for 4.4 - It is no functional change, but >>> quite a nice improvement in terms of code size. >> No functional change *if compilers are correct*. If they're not, for >> any reason, it will be very difficult to actually catch between now >> and the release. >> >> I'm not inclined to think that a reduction of 6k is a big enough >> improvement to take the risk at this point. >> >> -George > Patch 1 is literally just textual replacement, cleaning up its current > uses in the codebase. > > Patch 2 applies its use to more functions in the codebase. > > While I agree that it is "No functional change if compilers are > correct", this kind of paranoia could be applied to any and every patch > we consider taking. Anyway, Linux uses it far more than we do at the > moment. But what we're talking about here isn't just changing normal code flow or what-not; we're talking about a fairly niche optimization being applied to functions were it wasn't applied before. I would be willing to bet that "noreturn" has two or three orders of magnitude less usage and testing than anything in the "normal" C standard; that's why I consider it to be a higher risk than a patch which changes code in a "normal" way. Now sure, it's a fairly tiny risk, but the benefit is pretty tiny too. At the moment I don't see a good reason this can't wait until 4.5. -George