Page MenuHomePhabricator

[mlir] Optimize Operation field count memory usage
Needs ReviewPublic

Authored by rriddle on Nov 3 2021, 5:37 PM.



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).

Diff Detail

Event Timeline

rriddle created this revision.Nov 3 2021, 5:37 PM
rriddle requested review of this revision.Nov 3 2021, 5:37 PM

@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


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?

rriddle added inline comments.Nov 4 2021, 10:11 AM

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.