[all-commits] [llvm/llvm-project] 730ecb: [CGP] Convert phi types

[David Green via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 730ecb63ec0bac2ce83157d37bce4d2f7d4d1244
      https://github.com/llvm/llvm-project/commit/730ecb63ec0bac2ce83157d37bce4d2f7d4d1244
  Author: David Green <david.green at arm.com>
  Date:   2020-06-21 (Sun, 21 Jun 2020)

  Changed paths:
    M llvm/include/llvm/CodeGen/TargetLowering.h
    M llvm/lib/CodeGen/CodeGenPrepare.cpp
    M llvm/lib/Target/X86/X86ISelLowering.cpp
    M llvm/lib/Target/X86/X86ISelLowering.h
    M llvm/test/CodeGen/AArch64/convertphitype.ll
    A llvm/test/CodeGen/X86/convertphitype.ll

  Log Message:
  -----------
  [CGP] Convert phi types

If a collection of interconnected phi nodes is only ever loaded, stored
or bitcast then we can convert the whole set to the bitcast type,
potentially helping to reduce the number of register moves needed as the
phi's are passed across basic block boundaries. This has to be done in
CodegenPrepare as it naturally straddles basic blocks.

The alorithm just looks from phi nodes, looking at uses and operands for
a collection of nodes that all together are bitcast between float and
integer types. We record visited phi nodes to not have to process them
more than once. The whole subgraph is then replaced with a new type.
Loads and Stores are bitcast to the correct type, which should then be
folded into the load/store, changing it's type.

This comes up in the biquad testcase due to the way MVE needs to keep
values in integer registers. I have also seen it come up from aarch64
partner example code, where a complicated set of sroa/inlining produced
integer phis, where float would have been a better choice.

I also added undef and extract element handling which increased the
potency in some cases.

This adds it with an option that defaults to off, and disabled for 32bit
X86 due to potential issues around canonicalizing NaNs.

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