Consider using fixed scalar types#59
Conversation
| pub enum Type { | ||
| Bool, | ||
| SInt(IntWidth), | ||
| UInt(IntWidth), | ||
| Float(FloatWidth), | ||
| S8, | ||
| S16, | ||
| S32, | ||
| S64, | ||
| S128, | ||
| U8, | ||
| U16, | ||
| U32, | ||
| U64, | ||
| U128, | ||
| F16, | ||
| F32, | ||
| F64, | ||
| } |
There was a problem hiding this comment.
This is interesting in a way I hadn't considered.
I might be open to this if the actual hardcoded list was a private enum and Type was a struct newtype around it, what do you think?
For the record, the reason Type being 2 bytes is slightly suboptimal for me, is that you can actually pack (TypeKind, IntWidth) into 5 bits, and use the remaining 3 bits to also support vector types or something. It's not that important, just a thought exercise I started ages ago (for LLVM IR types, once you remove pointee types, and arrays/structs, because the only nesting left is vector types around scalar types).
There was a problem hiding this comment.
I might be open to this if the actual hardcoded list was a private enum and Type was a struct newtype around it, what do you think?
Did that in 1bdf588 - what do you think?
eddyb
force-pushed
the
scalar
branch
3 times, most recently
from
5eefbcf to
ad22784
Compare
2 participants
Just an experiment to try out a different approach, haven't checked it in detail.