On Mon, Feb 12, 2007 at 12:55:00PM +0000, Andrew Haley wrote:
> Christopher Layne writes:
> > On Sun, Feb 11, 2007 at 03:56:39PM +0000, Andrew Haley wrote:
> > > With your unaltered source code, I get this at -O3:
> > >
> > > main:
> > > .LFB28:
> > > subl $1, %edi
> > > pushq %rbx
> > > .LCFI1:
> > > movl $1, %eax
> > > movq %rsi, %rbx
> > > jle .L8
> > > movl $16, %edi
> > > call malloc
> > > movq 8(%rbx), %rdx
> > > movq stdout(%rip), %rdi
> > > movl $.LC0, %esi
> > > movq $cbt_display, 8(%rax)
> > > movq %rdx, (%rax)
> > > xorl %eax, %eax
> > > call fprintf
> > > xorl %eax, %eax
> > > .L8:
> > > popq %rbx
> > > ret
>
> Oh yeah. The reason you don't get the inlining is that the inlining
> pass is done before the assignment has been propagated.
>
>[...]
>
> In general, inlining early is a win, becasue it exposes many
> opportunites that would otherwise be hidden.
>
> This is one of the penalties of early inlining. I suppose we could
> attempt to inline again at the end of optimization, and maybe this
> would reveal a few opportunities we'd missed, but in most cases it
> wouldn't be worthwhile.
>
> Andrew.
I see. A couple of things:
1. Any kind of loop construct goes back to indirection, and not even
a direct call:
/* for (i = 0; i < 1024; i++) c->display(c); */
.L9:
movl %esi, (%esp)
incl %ebx
call *4(%esi)
cmpl $1024, %ebx
jne .L9
xorl %eax, %eax
I would figure that it would atleast keep it "call cbt_display" and
just not inline it. But this probably has something to do with the
order in which loop unrolling is done before the assignment has
propgated, similar to the inline case?
2. Using -fprofile-generate, exec, -fprofile-use. It uses indirection
everytime. My weak hope being that it would see, from profiling data,
it was just calling a static function in the same module and inline it,
but no go. :D
3. How do you think this might play into things:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01205.html
-cl
