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

Yerk! This would throw a serious wrench in supporting non power of two vector lengths, which is needed by us. We needed to add v3f32 and v3i32 ValueTypes just to define our register file in the .td.

Ok. You'll probably want to have dedicated simple values for vector types

which are legal, and those would still fit within the initial 5 (or maybe

6) bits. But then you may want to do things like v6f32 and so on, so

you'll still need more flexibility than the log2 encoding.

I'm ok with a linear encoding for extended vector lengths. I don't know

offhand how many bits will be needed for it, so I don't know how many

bits that leaves for arbitrary bitwidth integers and such, but this may

be a situation where we shouldn't worry it until someone actually wants

to do it.

Dan

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.

ooh simple is good

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?

Hrm, interesting. If you do this, please reserve 6 bits for the simple VTs, to permit future expansion without having to shuffle bits around.

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.

As Christopher says, I think that non-power-of-two vectors are going to be important in the future. That said, I wouldn't have a problem with limiting vector width to be something capped, say at 4096 elements? If people want really large vectors we could bump this up in the future.

I don't have any code written yet; I wanted to run the idea by the list

first :-).

Sounds very interesting!

-Chris