[all-commits] [llvm/llvm-project] 966ae7: Run update_llc_test on test/CodeGen/ARM/vmov.ll

[john-brawn-arm via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 966ae762229f9d77e6d9f0ab4220e4c2bf5f4fc4
      https://github.com/llvm/llvm-project/commit/966ae762229f9d77e6d9f0ab4220e4c2bf5f4fc4
  Author: John Brawn <john.brawn at arm.com>
  Date:   2020-04-03 (Fri, 03 Apr 2020)

  Changed paths:
    M llvm/test/CodeGen/ARM/vmov.ll

  Log Message:
  -----------
  Run update_llc_test on test/CodeGen/ARM/vmov.ll

This is in preparation for D76514


  Commit: cd58fb632533e9bb87d401b734fcfec62012276d
      https://github.com/llvm/llvm-project/commit/cd58fb632533e9bb87d401b734fcfec62012276d
  Author: John Brawn <john.brawn at arm.com>
  Date:   2020-04-03 (Fri, 03 Apr 2020)

  Changed paths:
    M llvm/lib/Target/ARM/ARMISelLowering.cpp
    M llvm/test/CodeGen/ARM/vmov.ll
    M llvm/test/CodeGen/Thumb2/mve-masked-load.ll
    M llvm/test/CodeGen/Thumb2/mve-vmovimm.ll

  Log Message:
  -----------
  [ARM] Avoid pointless vrev of element-wise vmov

If we have an element-wise vmov immediate instruction then a subsequent vrev
with width greater or equal to the vmov element width, then that vrev won't do
anything. Add a DAG combine to convert bitcasts that would become such vrevs
into vector_reg_casts instead.

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


  Commit: 4ad9ca0f9e1b501ddf0ca4082c459d98046c93c2
      https://github.com/llvm/llvm-project/commit/4ad9ca0f9e1b501ddf0ca4082c459d98046c93c2
  Author: John Brawn <john.brawn at arm.com>
  Date:   2020-04-03 (Fri, 03 Apr 2020)

  Changed paths:
    M llvm/lib/Target/ARM/ARMISelLowering.cpp
    M llvm/test/CodeGen/ARM/big-endian-neon-fp16-bitconv.ll
    A llvm/test/CodeGen/ARM/big-endian-vmov.ll
    M llvm/test/CodeGen/ARM/vmov.ll
    M llvm/test/CodeGen/Thumb2/mve-vmovimm.ll

  Log Message:
  -----------
  [ARM] Fix incorrect handling of big-endian vmov.i64

Currently when the target is big-endian vmov.i64 reverses the order of the two
words of the vector. This is correct only when the underlying element type is
32-bit, as actually what it should be doing is considering it a vector of the
underlying type and reversing the elements of that.

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


Compare: https://github.com/llvm/llvm-project/compare/6d24dd7ed119...4ad9ca0f9e1b