From: Paolo Bonzini <pbonzini@redhat.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Anthony Liguori <aliguori@amazon.com>,
kvm-devel <kvm@vger.kernel.org>,
Patch Tracking <patches@linaro.org>,
QEMU Developers <qemu-devel@nongnu.org>,
Andreas Tobler <andreast@freebsd.org>,
Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Qemu-devel] [PATCH for-1.7] target-i386: Fix build by providing stub kvm_arch_get_supported_cpuid()
Date: Tue, 12 Nov 2013 15:57:36 +0100 [thread overview]
Message-ID: <528241E0.5060503@redhat.com> (raw)
In-Reply-To: <20131112140935.GD2008@redhat.com>
Il 12/11/2013 15:09, Gleb Natapov ha scritto:
> On Tue, Nov 12, 2013 at 02:57:49PM +0100, Paolo Bonzini wrote:
>> Il 12/11/2013 14:23, Gleb Natapov ha scritto:
>>>> If -O0 does not do that, let's move debug builds to -O1.
>>>
>>> Why not enable dce with -fdce?
>>
>> First, because clang doesn't have fine-tuned optimization options (at
>> least I couldn't find them and -fdce doesn't work).
>
> -O1 then for clang.
We can even test in configure for the exact optimizations we want, in
fact. But I think -O1 doesn't sacrifice debuggability that much:
http://www.redhat.com/magazine/011sep05/features/gcc/
-O0 Barely any transformations are done to the code, just code
generation. At this level, the target code can be debugged with
no loss of information.
-O1 Some transformations that preserve execution ordering.
Debuggability of the generated code is hardly affected. User
variables should not disappear and function inlining is not
done.
-O2 More aggressive transformations that may affect execution
ordering and usually provide faster code. Debuggability may be
somewhat compromised by disappearing user variables and
function bodies.
Not very recent, but things have remained roughly the same and gdb also
has improved.
Hmm... I just found out that GCC has a shiny new "-Og" option to
optimize for debuggability and still producing good code. Using "-Og"
if it is present, and -O1 otherwise, seems like a good idea to me for
1.8. For 1.7 it can just be -O1.
>> Second, because most optimization options are no-ops at -O0 (try "-fdce
>> -fdump-tree-all" with GCC.
>>
> Strange. Is this by design? We can do -O1 and bunch of "-fno-" to
> disable most of optimizations -O1 enables, but this is ugly.
Yes, some data structures (I'm not up to date as to which exactly) are
not even built at -O0 to make compilation faster, and they're required
for most optimizations.
Paolo
next prev parent reply other threads:[~2013-11-12 14:58 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-11 21:22 [Qemu-devel] [PATCH for-1.7] target-i386: Fix build by providing stub kvm_arch_get_supported_cpuid() Peter Maydell
2013-11-11 21:28 ` Andreas Tobler
2013-11-11 22:19 ` Paolo Bonzini
2013-11-11 22:38 ` Peter Maydell
2013-11-11 23:11 ` Paolo Bonzini
2013-11-11 23:21 ` Anthony Liguori
2013-11-12 7:09 ` Paolo Bonzini
2013-11-12 11:07 ` Peter Maydell
2013-11-12 12:09 ` Paolo Bonzini
2013-11-12 12:16 ` Peter Maydell
2013-11-12 13:12 ` Paolo Bonzini
2013-11-12 13:21 ` Peter Maydell
2013-11-12 13:26 ` Gleb Natapov
2013-11-12 13:23 ` Gleb Natapov
2013-11-12 13:57 ` Paolo Bonzini
2013-11-12 14:09 ` Gleb Natapov
2013-11-12 14:14 ` Peter Maydell
2013-11-12 14:57 ` Paolo Bonzini [this message]
2013-11-12 15:13 ` Peter Maydell
2013-11-12 15:21 ` Paolo Bonzini
2013-11-12 15:32 ` Peter Maydell
2013-11-12 15:58 ` Paolo Bonzini
2013-11-12 16:08 ` Peter Maydell
2013-11-12 17:04 ` Anthony Liguori
2013-11-12 17:20 ` Peter Maydell
2013-11-12 18:54 ` Richard Henderson
2013-11-12 18:57 ` Peter Maydell
2013-11-12 19:15 ` Stefan Weil
2013-11-12 22:53 ` Paolo Bonzini
2013-11-13 2:27 ` Richard Henderson
2013-11-13 7:25 ` Paolo Bonzini
2013-11-13 22:23 ` Peter Maydell
2013-11-13 7:26 ` Gleb Natapov
2013-11-12 14:01 ` Peter Maydell
2013-11-11 23:23 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=528241E0.5060503@redhat.com \
--to=pbonzini@redhat.com \
--cc=aliguori@amazon.com \
--cc=andreast@freebsd.org \
--cc=anthony@codemonkey.ws \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=patches@linaro.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).