Re: Register Allocation Bug?

[Andrew Haley <aph at redhat dot com>]

Kasper Bonne wrote:

> On Wed, Mar 25, 2009 at 12:41, Andrew Haley <aph@redhat.com> wrote:
>>> Since it hasn't been fixed maybe it's a bu..*ahem*..feature?
>> It's a feature.  Look up "earlyclobber" in the Fine Manual.
> 
> I tried that already and it does work but I actually thought the
> 'earlyclobber' modifier was for situations when the compiler couldn't
> otherwise know that a register would be, well, clobbered early. E.g.,
> when using 'rdtsc' or other instructions that modify a specific set of
> registers.

Earlyclobber is for the case where it's impossible to use the same
register for an output and an input.  For an example of where you *don't*
want an earlyclobber, something like this:

    asm ("add r0, r1, r2" : "r"(result) : "r"(n1), "r"(n2) : )

can quite legitimately use the same register for the output and one
of the inputs.

> In my example the compiler should be able to figure out that the
> register is not available for output (because it is used as input in
> the following line), so if this behavior is not a bug, it should
> be. IMO.

What following line?  All that gcc sees is a string which represents
an assembly instruction.  gcc depends on you to tell it what is an
earlyclobber.

> The wording in the description of digit constraints (like "0") lead me
> to believe that without such a constraint, the same register would not
> be used for both input and output... but OK, it doesn't say that
> explicitly.
> 
> Anyway, thanks for you answer...
> 
> On a side note, the assembler for your proposal is the following:
> 
>  1:       b8 00 00 00 00          mov    $0x0,%eax
>  2:       8b 0c 84                mov    (%esp,%eax,4),%ecx
>  3:       8d 14 84                lea    (%esp,%eax,4),%edx
>  4:       89 c8                   mov    %ecx,%eax
>  5:       89 45 fc                mov    %eax,0xfffffffc(%ebp)
>  6:       89 55 f0                mov    %edx,0xfffffff0(%ebp)
> 
> What is the point of line 4? Why not just:
> 
>  1:       b8 00 00 00 00          mov    $0x0,%eax
>  2:       8b 0c 84                mov    (%esp,%eax,4),%ecx
>  3:       8d 14 84                lea    (%esp,%eax,4),%edx
>  4:       89 45 fc                mov    %ecx,0xfffffffc(%ebp)
>  5:       89 55 f0                mov    %edx,0xfffffff0(%ebp)
> 
> So at least there is still room for optimizations.

There always is.  And probably always will be...

Andrew.