The motivation for this change is because we're interested in using bundle locked groups for Hexagon though want the option to relax previous instructions to satisfy alignment rather than only emitting nops.
The high level changes are creating two new fragment types, MCBundleLockFragment and MCBundleUnlockFragment and handling all the bundle logic in MCObjectStreamer rather than MCElfStreamer/MCAssembler.
computeBundlePadding was converted to MCBundleLockFragment::getSize which is queried when computing fragment size.
A function MCAssembler::writeNopData was extracted to write nop data according to bundling requirements.
I removed special functionality around relax-all handling. I'm not sure how much assemble-time memory it was saving but it was generating degenerate sequences of nops:
foo: 0: 55 pushl %ebp 1: 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 nopw %cs:(%eax,%eax) 10: 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 nopw %cs:(%eax,%eax) 1f: 90 nop 20: c7 04 24 01 00 00 00 movl $1, (%esp)
Memory usage will decrease during non bundle locked assembling due to the fact that the bundle lock members were removed from the MCFragment base class.
Is this illustration still true? Before, fragments with bundle padding had the "empty" padding space (the ###) followed by the content of the fragments. Now IIUC, there's just another fragment which is nothing but padding, correct? And now F->Offset just points to the beginning of the fragment, like any other fragment?