svn commit: r247460 - head/sys/dev/acpica

[Bruce Evans]

On Thu, 28 Feb 2013, Alexey Dokuchaev wrote:

> On Thu, Feb 28, 2013 at 11:27:02AM +0000, Davide Italiano wrote:
>> New Revision: 247460
>> URL: http://svnweb.freebsd.org/changeset/base/247460
>>
>> Log:
>>   MFcalloutng (r247427 by mav):
>>   We don't need any precision here. Let it be fast and dirty shift then
>>   slow and excessively precise 64-bit division.
>>
>> -    if (sbt >= 0 && us > sbt / SBT_1US)
>> -	us = sbt / SBT_1US;
>> +    if (sbt >= 0 && us > (sbt >> 12))
>> +	us = (sbt >> 12);
>
> Does this really buy us anything?

Only a little.

> Modern compilers should be smart enough to
> generate correct code.  Do you have evidence that this is not the case here?
> Not to mention that it obfuscates the code by using some magic constant.

Modern compilers aren't smart enough to generate optimal code for this.
But they can be helped by casting sbt to uint64_t before dividing it by
the power of 2.

Testing showed the following non-optimal code:
- clang on amd64: generates 2 extra shifts and 1 more addition for signed
   division.  It apparently doesn't notice that the tst ensures that sbt
   is >= 0.  It reduces the division to a shift but this needs fixups if
   the result might be negative.
- gcc on amd64: turns the division into a single shift without help.
- clang on i386: as on amd64.  Nice code except for the poor algorithm.
- gcc on i386: uses the poor algorithm and generates fairly horrible code
   for it, with about 6 more register move instuctions than clang.

Correct code for signed division by a power of 2 is different from
correct code for unsigned division by a power of 2.  The former can't
use a a shift, because C99 specifies division to be broken (that it
rounds towards zero).  C90 permitted signed division to work correctly
(to round towards minus infinity, or towards zero, in an
implementation-defined way), but most hardware does the broken rounding
so not many C implementations do correct rounding.

Bruce