Small refactoring of CodeGen classes to fix naming of CodeGen, make LLVM logic common.

This PR makes the naming of our CodeGen classes a bit more logical and eliminates duplicated code in compiling for LLVM. I originally started on this while tracking down the optimize_module crash, which turned out to be something else, but I feel this is an improvement to the code and sets up some other changes as follows:

1) Adding a top-level CodeGen class which is independent of LLVM. This should make some parts of StmtCompiler cleaner and can make it clear that functionality such as function_takes_user_context is not connected to LLVM.

2) CodeGen_Posix should go away. It has nothing to do with Posix and can either be folded in to CodeGen_LLVM, or made into a helper class. (CodeGen_Allocation or some such.)

3) All LLVM specific codegen for GPU backends should be built on Halide IR so that we can do things like call GPU code from the C backend. (There is not much of a use case for doing this from C, but it makes a lot of sense for a JavaScript backend, which I hope we will have.) Hopefully this will allow getting rid of the templated CodeGen_GPU_Host classes.
The use case is wrapper code which wants to choose between different
separately compiled filters at runtime. Our current implementation is
ad-hoc and passes strings around.


On Fri, Nov 21, 2014 at 1:52 PM, Andrew Adams <notifications@github.com>
wrote:

> In src/CodeGen_LLVM.cpp:
>
> >                        const vector<Argument> &args,
> >                        const vector<Buffer> &images_to_embed) {
> > +    init_module();
> > +
> > +    // Fix the target triple
> > +    module = get_initial_module_for_target(target, context);
> > +
> > +    llvm::Triple triple = get_target_triple();
>
> Moving the Halide::Internal portion of Target.h/cpp into it's own module
> seems good, but what's the use-case for Target at runtime?
> … <#149d457c6d490e29_>
> On Fri, Nov 21, 2014 at 1:46 PM, Zalman Stern <notifications@github.com>
> wrote: In src/CodeGen_LLVM.cpp: > const vector<Argument> &args, > const
> vector<Buffer> &images_to_embed) { > + init_module(); > + > + // Fix the
> target triple > + module = get_initial_module_for_target(target, context);
> > + > + llvm::Triple triple = get_target_triple(); I also want most of
> Target to endup in the C++ runtime code. That is it becomes .h file only
> and can be used in programs which do not link against libHalide.a. — Reply
> to this email directly or view it on GitHub <
> https://github.com/halide/Halide/pull/560/files#r20744419>.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/halide/Halide/pull/560/files#r20744753>.
>