From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 4 09:16:07 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E3F72238; Mon, 4 Mar 2013 09:16:07 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8D3FE81E; Mon, 4 Mar 2013 09:16:07 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:204:4bff:fe01:de8a] (spaceball.andric.com [IPv6:2001:7b8:3a7:0:204:4bff:fe01:de8a]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 29CC35C43; Mon, 4 Mar 2013 10:16:04 +0100 (CET) Message-ID: <51346650.90200@FreeBSD.org> Date: Mon, 04 Mar 2013 10:16:00 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Matt Burke , Andriy Gapon Subject: Re: clang generated code sometimes confuses fbt References: <5132387E.8010808@FreeBSD.org> <513453D4.4010305@icritical.com> In-Reply-To: <513453D4.4010305@icritical.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 09:16:08 -0000 On 2013-03-04 08:57, Matt Burke wrote: > On 03/02/13 17:35, Andriy Gapon wrote: >> To summarize: I would be glad of either clang generated code was >> "fbt-friendly" or if ctf information was generated for >> bpobj_iterate_impl. Either is perfect for me. > > Apologies if this is a silly suggestion, but are you building with -O0? > I've noticed backtraces being hard to follow (i.e. skipping intermediate > and wrapper functions) with a kernel built with the default optimisation > level, and it seems to me that the same thing may be happening here - the > wrappers are being optimised out. No, the wrappers (bpobj_iterate and bpobj_iterate_nofree) are externally visible functions, so they cannot be optimized out. Both of them call bpobj_iterate_impl, which is a static function, e.g. a candidate for automatic inlining. However, bpobj_iterate_impl is quite big, and called from 3 different locations, so it does not actually get inlined, even with -O2.