Subzero: Fix symbol name mangling. Make flags global.

src/IceClFlags.h

Index: src/IceClFlags.h
diff --git a/src/IceClFlags.h b/src/IceClFlags.h
index d3e8b26510b512454b8bdd50afa03c7bad7dc18f..d10c8c4d26bfb5c5f0b342e11726053ad196ae8a 100644
--- a/src/IceClFlags.h
+++ b/src/IceClFlags.h
@@ -20,6 +20,21 @@
 
 namespace Ice {
 
+// TODO(stichnot): Fix the separation between ClFlags and ClFlagsExtra.
+//
+// The original intention was that ClFlags would be the core set of flags for a
+// release build, while ClFlagsExtra had optional flags that would be locked to
+// default values in a release build.  However, the division has evolved to be
+// fairly arbitrary.
+//
+// The variable flags in a release (browser) build should be limited to opt
+// level, number of threads, output file, and perhaps input file.
+//
+// The core flags should remain part of the GlobalContext object, but the
+// optional flags might as well be global, i.e. static members of GlobalContext,

[John, 2016/03/06 22:39:38]

If they are global, please make them, uh, global!

[Jim Stichnoth, 2016/03/07 00:03:10]

Do you mean just pull them out of the Ice::GlobalContext namespace into the Ice
namespace?

In any case, I was hoping to defer the full cleanup of flags into a separate CL.
 The idea is to keep actual parameters to the browser translation in a
GlobalContext specific object, and make the rest global.  The core parameters
are just optlevel, numthreads, and output file.  In the browser build, those
would have a simple command line parser rather than using llvm::cl, and all the
others would be hard-coded.  This would reduce the size of the translator by
maybe 50-100KB.  Since the core parameters would use the same non-global
plumbing as the existing flags, I kept that plumbing reasonably intact to make
the implementation easier.

[John, 2016/03/07 16:41:08]

Yes, just move it to the Ice namespace. There's very little value added in
having static members like these. In general, this kind of construct "smells"
like java -- which lacks globals.

If you are "worried" about "naked" uses of these member, you could move their
declaration to some cpp file, and just expose the getters -- which have no real
reason to be class members.

+// so that they are easily accessed from anywhere without needing to plumb in
+// the GlobalContext object.
+
 class ClFlagsExtra;
 
 /// Define variables which configure translation and related support functions.