[LLVMdev] a possible alternative for pre-legalize extended ValueTypes

Dan Gohman djg at cray.com
Fri Jun 22 11:06:33 PDT 2007


After doing a bunch of work for moving pre-legalize extended ValueTypes
into a table in SelectionDAG, I may have just found a simpler approach.

There are under 32 simple ValueType values, so we only really need 5 bits
to represent those. ValueType is already a 32-bit type on most hosts; what
if we make use of the remaining 27 bits instead of using an external
table?

If we can assume that vector lengths will always be a fixed multiple of 2,
we can encode vector lengths for extended vector types as the log2 of the
length, biased by one. Using only 6 bits gets us vector lengths up to
(2**64)-2, which Ought To Be Enough For Anyone. The bias allows an all-zero
pattern to be available to be interpreted as a scalar type, while still
permitting encodings of vectors with length 1, distinct from scalars.

That's 11 bits used, so we've got 21 left to play with, for arbitrary-size
integers, custom floating-point formats, or whatever else. It would be
less if we need to support non-power-of-two vector lengths. Either way,
it's less that can be imagined being used, if people get into this kind of
thing. However, maybe we can get by with creating encodings.

If the high 27 bits of a ValueType are all zero, then it's a simple
ValueType, and it can be used directly to index various tables.

Obviously there would be helper functions to encapsulate all of this
encoding complexity.

I don't have any code written yet; I wanted to run the idea by the list
first :-).

Dan

-- 
Dan Gohman, Cray Inc.



More information about the llvm-dev mailing list