problems with optimisation

Kicer kicer86@gmail.com
Fri Dec 28 17:14:00 GMT 2012


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



More information about the Gcc-help mailing list