How inlined are inlined functions?

[Mark Mitchell]

>>>>> "Jim" == Jim Blandy <jimb@cygnus.com> writes:

    Jim> I've noticed that I get worse code when I used inlined
    Jim> functions than I do when I use a macro.  I understand that
    Jim> argument passing to inlined functions is not right, and Mark
    Jim> Mitchell is working on this, but the problem I'm seeing seems
    Jim> to be related to the returned value.

The new inlining-on-trees should rectify almost all of these problems.
Like macros, the inlining now happens on the source level, before the
RTL back-end gets involved.  (In fact, we can now inline some
functions that the RTL back-end refused to inline, such as those with
particularly odd return-types, or those that contain setjmp.)

On your example:

  linux1.codesourcery.com% test-g++ -O2 -DINLINE -S -o test.inline.s test.C
  linux1.codesourcery.com% test-g++ -O2 -DMACRO -S -o test.macro.s test.C
  linux1.codesourcery.com% diff test.macro.s test.inline.s 
  linux1.codesourcery.com% 

So, the same code is generated in both cases.  It is, however:

  foo__FPi:
  .LFB1:
	  pushl	%ebp
  .LCFI0:
	  movl	%esp, %ebp
  .LCFI1:
	  subl	$8, %esp
  .LCFI2:
	  movl	8(%ebp), %eax
	  movb	(%eax), %al
	  xorb	$1, %al
	  andl	$1, %eax
	  je	.L2
	  call	bar__Fv
  .L2:
	  movl	%ebp, %esp
	  popl	%ebp
	  ret

But, since the same code happens using the macro, you can't fault the
inliner! 

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com