llvmGen: Use pprPanic instead of open-coded alternative
llvmGen: Compatibility with LLVM 3.5

Due to changes in LLVM 3.5 aliases now may only refer to definitions.
Previously to handle symbols defined outside of the current commpilation
unit GHC would emit both an `external` declaration, as well as an alias
pointing to it, e.g.,

    @stg_BCO_info = external global i8
    @stg_BCO_info$alias = alias private i8* @stg_BCO_info

Where references to `stg_BCO_info` will use the alias
`stg_BCO_info$alias`. This is not permitted under the new alias
behavior, resulting in errors resembling,

    Alias must point to a definition
    i8* @"stg_BCO_info$alias"

To fix this, we invert the naming relationship between aliases and
definitions. That is, now the symbol definition takes the name
`@stg_BCO_info$def` and references use the actual name, `@stg_BCO_info`.
This means the external symbols can be handled by simply emitting an
`external` declaration,

    @stg_BCO_info = external global i8

Whereas in the case of a forward declaration we emit,

    @stg_BCO_info = alias private i8* @stg_BCO_info$def
Total hack but it seems  to work
hi
It works?
Slight cleanup
One more cleanup
More cleanup
Add comments
Don't export everything with external linkage
More explanation
More comments
llvmGen: Compatibility with LLVM 3.5

Summary:
Due to changes in LLVM 3.5 aliases now may only refer to definitions.
Previously to handle symbols defined outside of the current commpilation
unit GHC would emit both an `external` declaration, as well as an alias
pointing to it, e.g.,

    @stg_BCO_info = external global i8
    @stg_BCO_info$alias = alias private i8* @stg_BCO_info

Where references to `stg_BCO_info` will use the alias
`stg_BCO_info$alias`. This is not permitted under the new alias
behavior, resulting in errors resembling,

    Alias must point to a definition
    i8* @"stg_BCO_info$alias"

To fix this, we invert the naming relationship between aliases and
definitions. That is, now the symbol definition takes the name
`@stg_BCO_info$def` and references use the actual name, `@stg_BCO_info`.
This means the external symbols can be handled by simply emitting an
`external` declaration,

    @stg_BCO_info = external global i8

Whereas in the case of a forward declaration we emit,

    @stg_BCO_info = alias private i8* @stg_BCO_info$def

Test Plan: Validate with LLVM 3.4 and 3.5

Reviewers: scpmw, austin

Subscribers: simonmar, relrod, ezyang, carter

Differential Revision: https://phabricator.haskell.org/D155

GHC Trac Issues: #9142
LlvmMangler: Be more selective when mangling object types

Summary:
We previously did a wholesale replace of `%function` to `%object` to
mangle object `.type` annotations. This is bad as it can end up
replacing appearances of `"%function"` in the user's code. We now look
for a proper `.type` keyword before performing the replacement.

Thanks to @rwbarton for pointing out the bug.

Test Plan:
Previously,

    $ echo 'main = putStrLn "@function"' > test.hs
    $ ghc -fllvm test.hs
    $ ./test
    @object

Now,
    $ echo 'main = putStrLn "@function"' > test.hs
    $ ghc -fllvm test.hs
    $ ./test
    @function

Reviewers: rwbarton, austin

Reviewed By: rwbarton, austin

Subscribers: phaskell, simonmar, relrod, ezyang, carter

Differential Revision: https://phabricator.haskell.org/D150

GHC Trac Issues: #9439
Make configure's sed(1) expression for GHC_LDFLAGS more BSD-friendly.
Implement {resize,shrink}MutableByteArray# primops

The two new primops with the type-signatures

  resizeMutableByteArray# :: MutableByteArray# s -> Int#
                          -> State# s -> (# State# s, MutableByteArray# s #)

  shrinkMutableByteArray# :: MutableByteArray# s -> Int#
                          -> State# s -> State# s

allow to resize MutableByteArray#s in-place (when possible), and are useful
for algorithms where memory is temporarily over-allocated. The motivating
use-case is for implementing integer backends, where the final target size of
the result is either N or N+1, and only known after the operation has been
performed.

A future commit will implement a stateful variant of the
`sizeofMutableByteArray#` operation (see #9447 for details), since now the
size of a `MutableByteArray#` may change over its lifetime (i.e before
it gets frozen or GCed).

Test Plan: ./validate --slow

Reviewers: ezyang, austin, simonmar

Reviewed By: austin, simonmar

Differential Revision: https://phabricator.haskell.org/D133
Fix typos 'resizze'
Revert "Fix typos 'resizze'"
this is z-encoding (as hvr tells me)

This reverts commit 425d5178af55620efa00e6e16426f491c63ad533.
Workaround GCC `__ctzdi2` intrinsic linker errors

On Linux/i386 the 64bit `__builtin_ctzll()` instrinsic doesn't get
inlined by GCC but rather a short `__ctzdi2` runtime function is
inserted when needed into compiled object files.

This causes failures for the four test-cases

  TEST="T8639_api T8628 dynCompileExpr T5313"

with error messages of the kind

  dynCompileExpr: .../libraries/ghc-prim/dist-install/build/libHSghcpr_BE58KUgBe9ELCsPXiJ1Q2r.a: unknown symbol `__ctzdi2'
  dynCompileExpr: dynCompileExpr: unable to load package `ghc-prim'

This workaround forces GCC on 32bit x86 to to express `hs_ctz64` in
terms of the 32bit `__builtin_ctz()` (this is no loss, as there's no
64bit BSF instruction on i686 anyway) and thus avoid the problematic
out-of-line runtime function.

Note: `__builtin_ctzll()` is used since
      e0c1767d0ea8d12e0a4badf43682a08784e379c6 (re #9340)
Remove obsolete `digitsTyConKey :: Unique`

This became dead with 1e87c0a6e485e1dbef8e9ed19191e54f6cdc54e0
and was probably just missed.

I plan to re-use the freed up `mkPreludeTyConUnique 23` slot soon
for a new `bigNatTyConKey` (as part of the #9281 effort)