* margnus1/hipe-call-elim-crash/PR-1253:
  hipe_icode_call_elim: Fix cf elimination crash
  hipe: Improve error message on internal crashes

Suggested by Kostis.

hipe_icode_call_elim could in some cases replace an #icode_call{} with
control flow with a move instruction. This would break the control flow
graph invariants and cause a crash.

Print the MFA/module being compiled, and pretty-print the backtrace with
lib:format_stacktrace/4.

Additionally, make the error_msg/2 macro in hipe.hrl respect the
HIPE_LOGGING define, since messages produced by this macro just before
runtime shutdown were sometimes lost (since code_server:error_msg/2 is
asynchronous).

* margnus1/hipe_llvm39_bugs/PR-1237:
  hipe_rtl_to_llvm: Constants for bits per byte/word
  hipe_llvm: Work around LLVM 3.9 sdesc bug
  hipe_llvm: Fix incorrect atom alignment assumption

The constant ?WORD_WIDTH is renamed ?BITS_IN_WORD, and a new constant
?BITS_IN_BYTE is introduced.

Additionally, a bug in a currently unused case clause of
llvm_type_from_size/1 is fixed (the size of a word was hardcoded to 64
bits).

As of LLVM 3.9, the x86-call-frame-opt pass in LLVM's X86 backend causes
the stack descriptors to contain incorrect (or even negative) frame
sizes or root slot offsets.

This might cause LLVM-compiled modules to be rejected during loading
with a badarg exception in hipe_bifs:enter_sdecs/1 (which additionally
prints a "hipe_bifs_enter_sdesc_1: bad sdesc!" message to stderr), or it
might cause corruption or segmentation faults when walking stacks (f.ex.
during GC) containing frames compiled with ErLLVM.

As a workaround, we pass the -no-x86-call-frame-opt flag to llc when
the version is at least 3.9

ErLLVM was declaring atoms in the following manner:

    @atom_ok = external constant i64
    ; Used inside a function like this
    %var = ptrtoint i64* @atom_ok to i64

However, doing so makes LLVM think the `atom_ok` is 8-byte aligned,
since it refers to a i64 value. This resulted in LLVM occasionally
incorrectly optimising away type tests on atoms, causing incorrect
behaviour or even segfaults. One such case is in
bs_match_compiler:coverage_apply/2, in which an is_boxed test on a
literal atom was optimised away, causing the code to try and load the
"header" of an atom. This problem reproduces with LLVM versions 3.7
through 3.9.

By declaring atoms as i8 (byte) constants instead, LLVM no longer makes
these alignment assumptions, and the bug is fixed.