Subzero: Use CFG-local arena allocation for relevant containers.

src/IceConverter.cpp

Index: src/IceConverter.cpp
diff --git a/src/IceConverter.cpp b/src/IceConverter.cpp
index 2e6021b82dcab0b2f23f5cee229b747ddd4367f6..cdfdc43580eb686134eba45e9e349794c15dd99d 100644
--- a/src/IceConverter.cpp
+++ b/src/IceConverter.cpp
@@ -83,7 +83,7 @@ public:
   Ice::Cfg *convertFunction(const Function *F) {
     VarMap.clear();
     NodeMap.clear();
-    Func = new Ice::Cfg(Ctx);
+    Func = Ice::Cfg::create(Ctx);

[JF, 2014/12/18 06:36:53]

The Cfg should probably be created (and deleted) where your thread is
created/deleted.

Though now that I think about it... Does it make sense to bound the allocator to
a single CFG? In LLVM we batch up a few functions per thread, so that as the
stream gets decoded we enqueue a few functions at a time into a worker to reduce
synchronization overhead. That would also reduce bump allocator creation
overhead, but it would increase memory usage.

[Jim Stichnoth, 2014/12/18 23:39:55]

I think the threading will work the following way.  Parsing and initial IR
creation is done in a single thread.  That thread adds new Cfgs to a work queue
(possibly self-throttling if the work queue gets too large).  Worker threads
grab Cfgs from the work queue and translate them, and add assembly buffers to a
write queue.  A separate writer thread grabs assembly buffers from the write
queue and linearizes them to disk.

This will affect how the allocator pointer gets stored into TLS, but
fundamentally I think each Cfg and its allocator need to be tightly coupled, and
each worker thread should translate more than one Cfg.

     Func->setFunctionName(F->getName());
     Func->setReturnType(convertToIceType(F->getReturnType()));
     Func->setInternal(F->hasInternalLinkage());