Re: [Qemu-devel] [PATCH v2] utils: Add pow2ceil()

[Richard Henderson <rth@twiddle.net>]

On 03/12/2015 09:45 AM, Eric Blake wrote:
> On 03/12/2015 09:29 AM, Richard Henderson wrote:
>> On 02/25/2015 02:45 AM, Markus Armbruster wrote:
>>> return 0x8000000000000000u >> (clz64(value - 1) - 1);
>>
>> I realize this was weeks ago, but it would certainly be preferable to shift a
>> small constant left than a large constant right.
>>
>> Most RISC machines can't form 0x8000000000000000ull without loading 1 and then
>> left shifting to start with.  So end the end you're better off with
>>
>>   return 1ull << (63 - clz64(value));
> 
> Since the value being shifted is a constant either way, can't gcc figure
> out the equivalence and generate the optimal code to begin with?  If
> not, should it be opened as a gcc bug for potential optimization?

With the simplest of tests,

unsigned long f(unsigned long x)
{
  return 1UL << (63 - x);
}

unsigned long g(unsigned long x)
{
  return 0x8000000000000000ul >> x;
}

the code is of similar size: 3 operations each.

But if you throw in the whole operation

  1ul << (63 - (__builtin_clzl(x - 1) - 1))
vs
  0x8...0ul >> (__builtin_clzl(x - 1) - 1)

then gcc is able to fold away one of the instructions and the 1UL alternative
is shorter.


r~