JIT throughput: CSE bitvector size, for x86

[BruceForstall]

The CSE package was changed recently from tracking CSEs using an int64 type to represent the CSE bitvector, to using our standard bitvector package. However, the CSE bitvector size was still set at 64. That means, for x86, using the “long” form of the bitvector: each one is a 32-bit pointer to a 64-bit array of bits, and all access is via a pointer indirection. This is much more costly than previously (and in JIT32).

Perhaps for x86 the CSE bitvector size should start at 32, so the "short" form of bitvector is used, and possibly that size change to something larger based on IR characteristics.

category:throughput
theme:ir
skill-level:intermediate
cost:small

[mikedn]

I think assertion prop is in the same boat as CSE, it too uses 64 bit bitvectors. There's some room for improvement in the bitvector ops area, might be worth checking that first before going to 32 bit bitvectors on x86. For example:

• bitvector allocation goes through a virtual function. With VC++ that costs us 2 indirect calls due to \guard:cf.
• bitvectors are initialized to 0 on allocation using a call to memset. Considering that they're normally small (assertion prop uses up to 256 bit bitvectors) that may be overkill
• it may be useful to have special support for dataflow equations in BitVecOps

[BruceForstall]

Notes: the CSE bit vector size is defined by EXPSET_SZ in block.h:

#if LARGE_EXPSET
#define EXPSET_SZ 64
#else
#define EXPSET_SZ 32
#endif

Large is always defined, in jit.h:

#define LARGE_EXPSET 1   // Track 64 or 32 assertions/copies/consts/rangechecks

Also, the cseTraits variable, used in every bitset operation, doesn't precompute GetArrSize(), so that code runs (including doing roundUp()) for every bitset operation.

If we really don't need the flexibility of dynamic short/long, we should implement a static array-based bitset, or maybe just use BitSetAsUInt64 again.

[TIHan]

Considering this is for throughput, it may be worth investigating.