search for: initializexxpass

...y for experimental purposes, but if test cases need to use those options, they would need a REQUIRES: asserts line. For options that we actually want to make available to tools (and general testing) we have a couple possibilities: Create a hook that can be called before command line parsing, like initializeXXPass. Raise those options into an API and define the command line interface at the tool level instead. This seems like something we want to do anyway, but I’m not proposing anything definite yet (I’m happy as long we’re moving in that direction). We may want to raise some options all the way to functio...

...need a REQUIRES: asserts line. Enh, I'm in favor of banning them. Even though I use a few. > > For options that we actually want to make available to tools (and general testing) we have a couple possibilities: > > Create a hook that can be called before command line parsing, like initializeXXPass. > This seems meh as just a workaround for the current behavior. It'd probably be a step forward, but might be more work than just doing... > Raise those options into an API and define the command line interface at the tool level instead. This seems like something we want to do anyway,...

Hi Andy, I definitely agree with the desire to remove command line options and having them be initialized as part of the pass would be general goodness. However, a few possible issues: a) a number of command line options aren't really connected to passes per-se (backend options) b) "As long as pass initialization happens before parseCommandLine, usage should be consistent." I'm

LLVM's internal command line library needs to evolve. We have an immediate need to build LLVM as a library free of static initializers, but before brute-force fixing this problem, I'd like outline the incremental steps that will lead to a desirable long term solution. We want infrastructure in place to provide an evolutionary path. In the near term, clients who need llvm-the-library with