Is this a feature ?

John Fine johnsfine@verizon.net
Mon May 11 17:56:00 GMT 2009


Why would that be considered either a feature or a bug?  I think it is 
neither, just an arbitrary behavior.

Deciding which variables and temporaries should go in which registers is 
a very hard problem.  Compilers generally don't do it very well 
(compared to skilled hand coding).  But not doing that well is not a 
"bug".  At most it is "room for improvement".

As your example demonstrates, the decisions of which variables and 
temporaries share registers can end up affecting the number of 
instructions needed for the code:

(reg&0xFF) can be computed in one instruction equally well when the 
result ends up in the same or different register than previously 
contained reg.

(reg >> 8) can be computed in one instruction with the result in the 
same register as previously contained reg.

So the choice of which temporary shares a register with the previous 
value of reg affects the need for the extra move instruction.  But it is 
hard for a compiler to bring the right knowledge to the right place to 
make this decision in the way that saves the move, vs. letting that 
happen or not by accident.

It also appears that in one version the same register was chosen for the 
new value of reg as for the old value.  I think that is also just an 
accident.  Depending on flow of control outside what you showed, those 
two values of reg are probably not the same variable from the viewpoint 
of the compiler.

raok@city.fi wrote:
>
> reg = (reg >> 8) ^ table[reg & 0xFF];
>
>
> It produced:
>
>         mov     edx, eax
>         movzx   eax, al
>         shr     dx, 8
>         xor     dx, WORD PTR [ebx+eax*2]
>
>
> I was wondering why there was that extra mov on the first line.  So I
> ended up to write it all as:
>
> reg = table[reg & 0xFF] ^ (reg >> 8);
>
>
> And it produced:
>
>
>         movzx   edx, al
>         shr     ax, 8
>         xor     ax, WORD PTR [ebx+edx*2]
>
>
> I do not know if this is a feature or bug but which ever it is, it would
> be nice to know.
>
>
>   



More information about the Gcc-help mailing list