[all-commits] [llvm/llvm-project] 0777c9: Make LLVM_APPEND_VC_REV=OFF affect clang, lld, and...

[Nemanja Ivanovic via All-commits]

  Branch: refs/heads/release/10.x
  Home:   https://github.com/llvm/llvm-project
  Commit: 0777c907268a8197de102f3770432b0f185de30a
      https://github.com/llvm/llvm-project/commit/0777c907268a8197de102f3770432b0f185de30a
  Author: Nico Weber <thakis at chromium.org>
  Date:   2020-06-23 (Tue, 23 Jun 2020)

  Changed paths:
    M clang/lib/Basic/CMakeLists.txt
    M lld/Common/CMakeLists.txt
    M lldb/source/CMakeLists.txt
    M llvm/cmake/modules/LLVMConfig.cmake.in
    M llvm/docs/CMake.rst

  Log Message:
  -----------
  Make LLVM_APPEND_VC_REV=OFF affect clang, lld, and lldb as well.

When LLVM_APPEND_VC_REV=OFF is set, the current git hash is no
longer embedded into binaries (mostly for --version output).
Without it, most binaries need to relink after every single
commit, even if they didn't change otherwise (due to, say,
a documentation-only commit).

LLVM_APPEND_VC_REV is ON by default, so this doesn't change the
default behavior of anything.

With this, all clients of GenerateVersionFromVCS.cmake honor
LLVM_APPEND_VC_REV.

Differential Revision: https://reviews.llvm.org/D72855

(cherry picked from commit fb5fafb23cc2d8613f8be2487afe94d8594a88ce)


  Commit: f5bad9cac5d38abdc3d9cc1f44bb1ab8198cc1df
      https://github.com/llvm/llvm-project/commit/f5bad9cac5d38abdc3d9cc1f44bb1ab8198cc1df
  Author: Yonghong Song <yhs at fb.com>
  Date:   2020-06-23 (Tue, 23 Jun 2020)

  Changed paths:
    M llvm/lib/Target/BPF/BPFISelDAGToDAG.cpp
    A llvm/test/CodeGen/BPF/rodata_5.ll

  Log Message:
  -----------
  [BPF] fix incorrect type in BPFISelDAGToDAG readonly load optimization

In BPF Instruction Selection DAGToDAG transformation phase,
BPF backend had an optimization to turn load from readonly data
section to direct load of the values. This phase is implemented
before libbpf has readonly section support and before alu32
is supported.

This phase however may generate incorrect type when alu32 is
enabled. The following is an example,
  -bash-4.4$ cat ~/tmp2/t.c
  struct t {
    unsigned char a;
    unsigned char b;
    unsigned char c;
  };
  extern void foo(void *);
  int test() {
    struct t v = {
      .b = 2,
    };
    foo(&v);
    return 0;
  }

The compiler will turn local variable "v" into a readonly section.
During instruction selection phase, the compiler generates two
loads from readonly section, one 2 byte load or 1 byte load, e.g., for 2 loads,
  t8: i32,ch = load<(dereferenceable load 2 from `i8* getelementptr inbounds
       (%struct.t, %struct.t* @__const.test.v, i64 0, i32 0)`, align 1),
       anyext from i16> t3, GlobalAddress:i64<%struct.t* @__const.test.v> 0, undef:i64
  t9: ch = store<(store 2 into %ir.v1.sub1), trunc to i16> t3, t8,
    FrameIndex:i64<0>, undef:i64

BPF backend changed t8 to i64 = Constant<2> and eventually the generated machine IR:
  t10: i64 = MOV_ri TargetConstant:i64<2>
  t40: i32 = SLL_ri_32 t10, TargetConstant:i32<8>
  t41: i32 = OR_ri_32 t40, TargetConstant:i64<0>
  t9: ch = STH32<Mem:(store 2 into %ir.v1.sub1)> t41, TargetFrameIndex:i64<0>,
      TargetConstant:i64<0>, t3

Note that t10 in the above is not correct. The type should be i32 and instruction
should be MOV_ri_32. The reason for incorrect insn selection is BPF insn selection
generated an i64 constant instead of an i32 constant as specified in the original
load instruction. Such incorrect insn sequence eventually caused the following
fatal error when a COPY insn tries to copy a 64bit register to a 32bit subregister.
  Impossible reg-to-reg copy
  UNREACHABLE executed at ../lib/Target/BPF/BPFInstrInfo.cpp:42!

This patch fixed the issue by using the load result type instead of always i64
when doing readonly load optimization.

Differential Revision: https://reviews.llvm.org/D81630

(cherry picked from commit 4db1878158a3f481ff673fef2396c12b7a53d280)


  Commit: 1f3be0e9b7b476780e5226aa95488a4a0a262961
      https://github.com/llvm/llvm-project/commit/1f3be0e9b7b476780e5226aa95488a4a0a262961
  Author: Nemanja Ivanovic <nemanja.i.ibm at gmail.com>
  Date:   2020-06-23 (Tue, 23 Jun 2020)

  Changed paths:
    M llvm/lib/Target/PowerPC/PPCInstrInfo.cpp
    A llvm/test/CodeGen/PowerPC/pr45432.ll

  Log Message:
  -----------
  [PowerPC] Do not assume operand of ADDI is an immediate

After pseudo-expansion, we may end up with ADDI (add immediate)
instructions where the operand is not an immediate but a relocation.
For such instructions, attempts to get the immediate result in
assertion failures for obvious reasons.

Fixes: https://bugs.llvm.org/show_bug.cgi?id=45432
(cherry picked from commit a56d057dfe3127c111c3470606c04e96d35b1fa3)


Compare: https://github.com/llvm/llvm-project/compare/97065683c6a9...1f3be0e9b7b4