patch for problem when mips16 hard float is linked as c++

[Daniel Sanders]

After making the following changes it will LGTM:
* clang-format the patch as raised by Rafael and Eric
* Fix the CMake build as you mentioned when we spoke earlier. For the benefit of the list, Reed noticed that the new .cpp files haven't been added to CMake yet.
* Remove the remaining commented out if-statement in MipsAsmPrinter::EmitFPCallStub(). It's near the end of the function

> -----Original Message-----
> From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-
> bounces at cs.uiuc.edu] On Behalf Of Reed Kotler
> Sent: 12 February 2014 18:04
> To: llvm-commits at cs.uiuc.edu
> Subject: patch for problem when mips16 hard float is linked as c++
> 
> 
> This patch has been rewritten to not use output raw text in MipsAsmPrinter
> and so is being sent out to the list before actual commit to make sure there
> are no further objections.
> 
> This patch has two main functions:
> 
> 1) Fix a specific bug when certain conversion functions are called in a program
> compiled as mips16 with hard float and the program is linked as c++. There
> are two libraries that are reversed in the link order with gcc/g++ and
> clang/clang++ for
> mips16 in this case and the proper stubs will then not be called. These stubs
> are normally handled in the Mips16HardFloat pass but in this case we don't
> know at that time that we need to generate the stubs. This must all be
> handled later in code generation and we have moved this functionality to
> MipsAsmPrinter. When linked as C (gcc or clang) the proper stubs are linked
> in from libc.
> 
> 2) Set up the infrastructure to handle 90% of what is in the Mips16HardFloat
> pass in this new area of MipsAsmPrinter. This is a more logical place to handle
> this and we have known for some time that we needed to move the code
> later and not implement it using inline asm as we do now but it was not clear
> exactly where to do this and what mechanism should be used. Now it's clear
> to us how to do this and this patch contains the infrastructure to move most
> of this to MipsAsmPrinter but the actual moving will be done in a follow on
> patch. The same infrastructure is used to fix this current bug as described in
> #1. This change was requested by the list during the original putback of the
> Mips16HardFloat pass but was not practical for us do at that time.