Kasper Bonne wrote:
> On Wed, Mar 25, 2009 at 12:41, Andrew Haley <aph@xxxxxxxxxx> 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.
