[llvm-commits] [PATCH] Optimize memory usage of MC bundling

[Eli Bendersky]

  Jim,

  A sample benchmark I'm using is assembling the whole of gcc 3.5 (packed into a single .s file). It's a pretty big benchmark. When bundling is enabled, the peak memory usage of llvm-mc grows from 360 to 610 MB. This is mainly due to the huge amount of fragments that get created (one per instruction). 1170K data fragments get created as opposed to just 200K with bundling disabled.

  With this patch, almost all the "extra" data fragments become "compact" fragments, and the memory usage falls to 490MB. Still a lot more than without bundling, but a big improvement for a relatively simple change. Even SmallVector<MCFixup, 1> takes 56 bytes on x86, which means 50MB extra for the case described above. As for making the default size of data fragments smaller, I decided against it precisely because I wanted to reduce the impact on the non-bundling case. I've been considering alternative approaches to make the hierarchy simpler, but couldn't come up with anything better. Template-based ideas produce overly complex code and a lot of verbosity. Perhaps multiple inheritance can be employed to create a mixin for "I have fixups", but do we really want MI?

  I want to stress that the effect of this on the nominal case (no bundling) manifests only in higher code complexity, which I'm trying to offset with good documentation. The current state of the code induces no compile/run-time price on the nominal case. It's just that in case bundling is enabled, somewhat different fragments get created. To adjust for that, the "user" code in the assembler that acts upon fragments was converted to act on interfaces, which may actually be better in terms of readability. If you recall, some earlier changes I made refactored stuff in preparation for this.

  If you have any specific suggestions on how to make this less intrusive, I'd love to hear them.

http://llvm-reviews.chandlerc.com/D270