Re: spurious asm movl with gcc 3.0 -fno-gcse

[Brad Lucier <lucier at math dot purdue dot edu>]

First of all, I'm not an expert in the internals of gcc.

Re:

> However, going over the assembly code I
> noticed an oddly spurious movl which isn't there with -fgcse:
> 
>          PUTLISTX:
> 
>         movl $8,%eax
>         shrl $1,%eax
>         movl _10FL_Manager.smmal(%eax),%ebx
>         movl (%ebx),%edx
>         movl %edx,_10FL_Manager.smmal(%eax)
>         testl %edx,%edx
>         jne .L7563
>         call refill__10FL_Manager
> .L7563:
>         movl %ebx,%edx          <<<<====== HERE
>         movl 4(%ebp),%eax
>         leal 3(%edx),%edi
>         addl $8,%ebp
>         movl %edi,(%eax)
>         movl %edx,448(%esp)
>         jmp *(%ebp)
>         .p2align 4,,7
> 
> why is this second sequence performing "movl %ebx,%edx" instead of
> just using %ebx?

I can't answer this question, and I doubt anyone else can, either.
I would guess that the amount of internal dumps and analysis that
one would need to answer this question definitively is prohibitive.

> If this is somehow due to turning off global common
> subexpresion elimination with -fno-gcse, then perhaps a finer level of
> tuning would be a good idea :-) or, perhaps, this simple, probably
> common case, ought to be recognized and dealt with in the obvious
> way.

Here's the deal: Computed gotos generate unsplittable (critical) edges in
the flow graph.  Until gcc-3.0 (prerelease), gcse could generate
incorrect code when working with flow graphs like this.  3.0 has
a more conservative algorithm that generates correct code (to the
best of our knowledge, of course), but code that may be much slower 
in the presence of computed gotos.

New algorithms have been proposed to do Lazy Code Motion (the
transformation that gcc uses for GCSE) in the presence of critical
edges, most notably in a paper by Oliver Ruething.  But that hasn't
been added to gcc, and I wouldn't recommend special casing this
transformation that may be of use to you now, but may not help in
an essentially identical loop later on.

So I think you're stuck for the moment.  Or maybe for the next
release or two.

Brad Lucier