[all-commits] [llvm/llvm-project] 4ae312: [LegalizeVectorOps][AArch64] Stop asking for v4f16...

topperc via All-commits all-commits at lists.llvm.org
Tue Dec 31 15:04:34 PST 2019


  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 4ae3120ed81cb2f1f73f59a52e2a9965515ea6bf
      https://github.com/llvm/llvm-project/commit/4ae3120ed81cb2f1f73f59a52e2a9965515ea6bf
  Author: Craig Topper <craig.topper at intel.com>
  Date:   2019-12-31 (Tue, 31 Dec 2019)

  Changed paths:
    M llvm/lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp
    M llvm/lib/Target/AArch64/AArch64ISelLowering.cpp

  Log Message:
  -----------
  [LegalizeVectorOps][AArch64] Stop asking for v4f16 fp_round and fp_extend to be promoted.

These operations are needed as building blocks for promoting so they
can't be promoted themselves.

This appeared to work because the fp_extend query type for operation
actions is the result type, not the input type so it never triggered
in the legalizer.

For fp_round, the vector op legalizer just ended up creating a
nop fp_extend that was elided by getNode, followed by a nop
fp_round that was also elided by getNode. This was followed by
a final fp_round from v4f32 back to vf416 which was CSEd to the
original node. Then legalize vector ops just believed that node
legalized to itself. LegalizeDAG took another crack at promoting
it, but didn't have a handler so just skipped it with a debug
message saying it wasn't promoted.

This patch just removes the operation actions to avoid this
non-sense. Found while trying to refactor LegalizeVectorOps to
handle multiple result nodes better.




More information about the All-commits mailing list