From: Kicer <kicer86@gmail.com>
To: David Brown <david@westcontrol.com>
Cc: Andrew Haley <aph@redhat.com>, gcc-help@gcc.gnu.org
Subject: Re: problems with optimisation
Date: Fri, 28 Dec 2012 17:14:00 -0000 [thread overview]
Message-ID: <4179792.vI8coZ6zEV@kicer> (raw)
In-Reply-To: <50DDC9F7.9070606@westcontrol.com>
Dnia piątek 28 grudnia 2012 17:33:59 David Brown pisze:
> On 28/12/12 16:19, Andrew Haley wrote:
> > With -O2 there's much less difference:
> >
> > bar(): bar():
> >
> > .LFB14: .LFB14:
> > .cfi_startproc .cfi_startproc
> > movl $3, %edx movl $3, %edx
> > in %dx, %al in %dx, %al
> >
> > movb $6, %dl | movb $4, %dl
> > movl %eax, %ecx movl %eax, %ecx
> > in %dx, %al in %dx, %al
> >
> > > movb $6, %dl
> > > movl %eax, %edi
> > > in %dx, %al
> >
> > movb $7, %dl movb $7, %dl
> > movl %eax, %esi movl %eax, %esi
> >
> > > andl $1, %edi
> >
> > in %dx, %al in %dx, %al
> >
> > movl %eax, %edi | movl %eax, %r8d
> >
> > > movsbl %sil, %esi
> >
> > movb $8, %dl movb $8, %dl
> > subb %dil, %cl | subb %r8b, %cl
> > in %dx, %al in %dx, %al
> >
> > andl $16, %esi | addl %edi, %ecx
> >
> > > testb $16, %sil
> >
> > setne %dl setne %dl
> >
> > > andl $1, %esi
> >
> > addl %edx, %ecx addl %edx, %ecx
> >
> > > subb %sil, %cl
> >
> > testb $16, %al testb $16, %al
> > setne %al setne %al
> > subb %al, %cl subb %al, %cl
> > movl %ecx, %eax movl %ecx, %eax
> > ret ret
> >
> > Without inlining GCC can't tell what your program is doing, and by using
> > -Os you're preventing GCC from inlining.
> >
> > Andrew.
>
> There are normally good reasons for picking -Os rather than -O2 for
> small microcontrollers (the OP is targeting AVRs, which typically have
> quite small program flash memories).
>
> So the solution here is to manually declare the various functions as
> "inline" (or at least "static", so that the compiler will inline them
> automatically). Very often, code that manipulates bits is horrible on a
> target like the AVR if the function is not inline, and the compiler has
> the bit number(s) as variables - but with inline code generation and
> constant folding, you end up with only an instruction or two for
> compile-time constant bit numbers.
>
> (To the OP) - also note that there can be significant differences in the
> types of code generation and optimisations for different backends. I
> assume you posted x86 assembly because you thought it would be more
> familiar to people on this list, but I think it would be more important
> to show the real assembly from the target you are using as you might see
> different optimisations or missed optimisations.
>
> Finally, there is a mailing list dedicated to gcc on the avr - it might
> be worth posting there too, especially if you think the issue is
> avr-specific.
>
> David
David: you are right - I used x86 due to its popularity ;)
In my real case I'm observing weird thigs (speaking of inline):
1. when in my code I use -Os and inline functions - gcc doesn't inline code
(and AFAIR, generates warning about it wont't inline because code would
grown).
Code looks funny then:
00000044
<_ZNK7OneWire14InterruptBasedILt56ELh4EE10releaseBusEv.isra.0.1569.1517>:
44: bc 98 cbi 0x17, 4 ; 23
46: 08 95 ret
plus a few calls like:
rcall .-262 ; 0x44
<_ZNK7OneWire14InterruptBasedILt56ELh4EE10releaseBusEv.isra.0.1569.1517>
those calls are completly useless as 'cbi' could be placed instead of them,
and the whole function actually consists of 1 command (except ret).
This is quite important for me as I loose certain amount of clock ticks here
:)
2. when I use -Os and always_inline attribute, I get a messy code like in my
first message (program gets bigger by 70%, and uses 2-3x more stack which is
half of available memory).
It's hard to place whole avr program here as it's big, and it's difficult to
introduce a smaller exmaple, because it's getting messy only when program gets
bigger.
Andrew: it's inconvenient to use O2 as Os produces a progam which size is 30%
of O2's result.
regards
--
Michał Walenciak
gmail.com kicer86
http://kicer.sileman.net.pl
gg: 3729519
next prev parent reply other threads:[~2012-12-28 17:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-28 10:25 Kicer
2012-12-28 15:19 ` Andrew Haley
2012-12-28 16:34 ` David Brown
2012-12-28 17:14 ` Kicer [this message]
2012-12-29 16:26 ` David Brown
2012-12-29 22:28 ` Ángel González
2012-12-30 9:51 ` Kicer
2012-12-30 11:25 ` David Brown
2012-12-30 9:47 ` Kicer
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=4179792.vI8coZ6zEV@kicer \
--to=kicer86@gmail.com \
--cc=aph@redhat.com \
--cc=david@westcontrol.com \
--cc=gcc-help@gcc.gnu.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 read-only IMAP folder(s) and NNTP newsgroup(s).