[RTG][Elaboration] Support sequences #7969
Conversation
| auto *curr = worklist.front(); | ||
| worklist.pop(); | ||
|
|
||
| if (table.lookup<SequenceOp>(curr->getName())) |
There was a problem hiding this comment.
SequenceValue doesn't have a getNameAttr. To return a StringAttr we'd need to first create one from the StringRef we get from name uniquing. However, if we just add a million sequences generated from a sequence family (result of sequence_closure op) to a set and only pick one, then we internalize almost a million attributes that we never use and attribute internalization is expensive. But yeah, this lookup would be faster, so it depends on the ratio of how many sequences end up being used. The name uniquing is actually consuming a big portion of the time in the outlined example case. So we might want to use IDs instead of directly generating unique names if it really becomes a bottleneck. It would complicate a few other things though, so need to be a bit careful with that.
75e65f4 to
1d5640f
Compare
* Simplify materializer to work on only one basic block * Remove unused addWorklist argument and use a class field instead * Because the way invocations are elaborated has changed, we don't need the worklist anymore within sequences or tests (we can just iterate over the operations since it's not a graph region), this is a big performance benefit in large tests/sequences. * Do a BFS over the sequence invocation hierarchy such that callees are only elaborated when all parents are elaborated (because only the `sequence_closure` operation should fix the randomization within a sequence, thus they create a clone before elaborating the referenced sequence) * Inline all sequences and remove them.
sequence_closureoperation should fix the randomization within a sequence, thus they create a clone before elaborating the referenced sequence)