[PATCH] [Polly][Unfinished][NFC] Restructure the command line options

[Johannes Doerfert]

>>! In D5762#9, @dpeixott wrote:
> This looks like a nice cleanup to me. I think centralizing the available options for polly makes sense. The major downside in my opinion is that we now have a bunch of global variables. Previously you could look at a command line option that is declared static (without external storage) and know it is only used in that file. Now we are exposing these all as global variables.
That is actually one of the reasons I came up with this patch. I want the options to be available to other LLVM pasess/projects, thus I have to expose them somehow. While I agree that global variables are not the best solution to this problem it is/was the easiest solution to allow me to configure Polly from within another project. Do you think we should wait/look for a different solution without the globals?

> As for the implementation, maybe we should consider using an `opt` or `options` namespace inside polly for all the command line options. This would make it clear when reading the code that we are referencing a command line option and we know where to look for the definition if needed.
Nice idea, I will do this.

> You are already essentially namespacing the variables by adding a `Polly` prefix. 
Indeed. Should I replace or add the opt namespace (what do you think?)
 
> We should also be aware of how llvm is changing command line options to move away from using static initializers: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075886.html. I'm not sure exactly what conclusion they came to, but we don't want to come with a design that will be incompatible with where the llvm community is headed.
I think this is not a blocking concern right now. As soon as they come to a conclusion we will adobpt it, however if we change 10 global variables to createXXXPass arguments then or 30 shouldn't make much of a difference. In the meantime we get closer to an organized and document way of handling command line options. We can reuse the documentation and structure also for the proposed new interface:

```
From:
  /// @brief Scheduler Options
  ///
  ///{
  
  /// @brief LaLaLa
  bool opt::PollyOption0;

  ///}

To:
  /// @brief Create Scheduling related passes
  ///
  ///{
  
  /// @brief XXX
  ///
  /// @bparam LaLaLa
  createXXXXPass(bool opt::PollyOption0);

  ///}

```
Do you think the discussion on the list blocks a refactoring like this?

[I talked to Tobias; he will be fine with any decision we come up with in our discussion here]

http://reviews.llvm.org/D5762