[llvm] r233689 - [SystemZ] Use POPCNT instruction on z196

Ulrich Weigand Ulrich.Weigand at de.ibm.com
Tue Mar 31 12:32:36 PDT 2015


Jay Foad <jay.foad at gmail.com> wrote on 31.03.2015 16:12:48:
> On 31 March 2015 at 13:56, Ulrich Weigand <ulrich.weigand at de.ibm.com>
wrote:
> > +  // Skip known-zero high parts of the operand.
> > +  int64_t BitSize = OrigBitSize;
> > +  while ((Mask & ((((uint64_t)1 << (BitSize / 2)) - 1) <<
> (BitSize / 2))) == 0)
> > +    BitSize = BitSize / 2;
>
> This will loop forever if all bits are known to be zero, won't it?
>
> To avoid looping, how about:
>
> unsigned NumSignificantBits = (~KnownZero).getActiveBits();
> unsigned BitSize = 1U << Log2_32_Ceil(NumSignificantBits);
>
> (But you still need to defend against all bits being zero.)

I couldn't manage to get the CTPOP expander called for a
known-zero input; I guess common code already simplifies
CTPOP(0) to 0.  But I agree it's certainly better to
handle the case here as well.

I've checked those changes in as r233736.

> For a 64-bit value where the high 32 bits are known to be zero
> you'll generate:
>
> Op = POPCNT(Op);
> Tmp = Op << 16;
> Tmp &= 0xFFFFFFFF;
> Op += Tmp;
> Tmp = Op << 8;
> Tmp &= 0xFFFFFFFF;
> Op += Tmp;
> Op >>= 24;
>
> Instead of doing an AND at every loop iteration, how about generating:
>
> Op = POPCNT(Op);
> Tmp = Op >> 16;
> Op += Tmp;
> Tmp = Op >> 8;
> Op += Tmp;
> Op &= 0xFF;
>
> I.e. SRL instead of SHL inside the loop, and AND instead of SRL to
> extract the overall result.

Well, the ANDs aren't real instructions, since they can always be
folded "for free" into either the shift (resulting in a RISB*
instruction) or the add (resulting in ALGFR).

Overall, it probably doesn't matter much which of the two possible
sequences we emit.  I've gone with the left-shift version since this
is what the Principles of Operation suggest; there is one potential
further optimisation in this case to implement the first shift by 32
and add (for the full 64-bit case) via an AHHLR (which LLVM also does
not implement yet, but might in the future).

Thanks for the review!

Bye,
Ulrich




More information about the llvm-commits mailing list