Various components within an operation (e.g. regions, results,
successors) have a small number of elements in the overwhelmingly
common case. This commit refactors Operation such that in the
common case, the counts of these fields are stored within a u8,
and in the extreme case the counts are stored in a trailing
object that allows for a full u32 number of elements. This allows
for dropping the size of Operation by 8 bytes (in an x64 we are
now down to 56 bytes).
Details
- Reviewers
lattner
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
@lattner I did some quick benchmarking and it didn't seem to have a negative impact on compile time, but can you try on your circt benchmarks?
awesome, I'll take a look as soon as we get your other work merged into the CIRCT llvm submodule
mlir/include/mlir/IR/Operation.h | ||
---|---|---|
725 | It'd be really awesome to make this be a full 'unsigned char' for the bool value, since it would make the accessors a single load+compare, instead of load+and+compare. Similarly hasOperandStorage is also going to be hot. Do you think that is possible without bloating things? |
mlir/include/mlir/IR/Operation.h | ||
---|---|---|
725 | I don't think we can as we are on a word boundary right now. We could make one of these a full char (given that the region/result/successor counts only use 3 bytes), but the other would need to steal a bit from somewhere else (orderIndex?). I'm not sure if it's worth it or not to go that route though. |
It'd be really awesome to make this be a full 'unsigned char' for the bool value, since it would make the accessors a single load+compare, instead of load+and+compare. Similarly hasOperandStorage is also going to be hot. Do you think that is possible without bloating things?