Fix a memory leak in the debug emission by simply not allocating memory.
There doesn't appear to be any reason to put this variable on the heap.
I'm suspicious of the LexicalScope above that we stuff in a map and then
delete afterward, but I'm just trying to get the valgrind bot clean.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187301 91177308-0d34-0410-b5e6-96231b3b80d8
Fix yet another memory leak found by the vg-leak bot. Folks (including
me) should start watching this bot more as its catching lots of bugs.

The fix here is to not construct the global if we aren't going to need
it. That's cheaper anyways, and globals have highly predictable types in
practice. I've added an assert to catch skew between our manual testing
of the type and the actual type just for paranoia's sake.

Note that this pattern is actually fine in most globals because when you
build a global with a module it automatically is moved to be owned by
that module. But here, we're in isel and don't really want to do that.
The solution of not creating a global is simpler anyways.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187302 91177308-0d34-0410-b5e6-96231b3b80d8
Create a constant pool symbol for the GOT in the ARMCGBR the same way we
do in the SDag when lowering references to the GOT: use
ARMConstantPoolSymbol rather than creating a dummy global variable. The
computation of the alignment still feels weird (it uses IR types and
datalayout) but it preserves the exact previous behavior. This change
fixes the memory leak of the global variable detected on the valgrind
leak checking bot.

Thanks to Benjamin Kramer for pointing me at ARMConstantPoolSymbol to
handle this use case.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187303 91177308-0d34-0410-b5e6-96231b3b80d8