Subzero: Fix symbol name mangling. Make flags global.

src/IceClFlags.h

 //===- subzero/src/IceClFlags.h - Cl Flags for translation ------*- C++ -*-===//
 //
 //                        The Subzero Code Generator
 //
 // This file is distributed under the University of Illinois Open Source
 // License. See LICENSE.TXT for details.
 //
 //===----------------------------------------------------------------------===//
 ///
 /// \file
 /// \brief Declares Ice::ClFlags which implements command line processing.
 ///
 //===----------------------------------------------------------------------===//
 
 #ifndef SUBZERO_SRC_ICECLFLAGS_H
 #define SUBZERO_SRC_ICECLFLAGS_H
 
 #include "IceDefs.h"
 #include "IceTypes.h"
 
 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.
 class ClFlags {
   ClFlags(const ClFlags &) = delete;
   ClFlags &operator=(const ClFlags &) = delete;
 
 public:
   using StringVector = std::vector<IceString>;
 
@@ skipping 459 matching lines @@
   /// see anonymous_namespace{IceClFlags.cpp}::NumThreads
 
   size_t NumTranslationThreads; // 0 means completely sequential
   /// see anonymous_namespace{IceClFlags.cpp}::RandomSeed
   uint64_t RandomSeed;
 };
 
 } // end of namespace Ice
 
 #endif // SUBZERO_SRC_ICECLFLAGS_H