[PATCH] D76705: [SystemZ] Improve foldMemoryOperandImpl: vec->FP conversions

Ulrich Weigand via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri May 8 09:37:56 PDT 2020


uweigand added a comment.

In D76705#2020342 <https://reviews.llvm.org/D76705#2020342>, @jonpa wrote:

> Reverted back to the first version of new instruction classes providing the mapping from W...-reg -> FP-mem instructions.


Thanks.   Let my try one final attempt to simply this confusing logic :-)

Right now, we have:

- For UnaryVRRa and CompareVRRa, the OpKey holds the FP-reg instruction name (e.g. wldeb->ldebr or wfsqsb->sqebr), which the matches the "mem" OpKey for the normal FP-mem instruction.
- For BinaryVRRa and TernaryVRRe, the OpKey holds the W-reg instruction name, which matches the "mem" OpKey of the MemFold-pseudo, which has the FP-reg instruction name as MemKey.

Can we instead move the W->FP mnemonic conversion back into BinaryVRRa/TernaryVRRe instead, so that the OpKey for all these vector instructions consistently holds the FP-reg instruction name?  The MemFold-pseudos would then have the same mnemonic as OpKey and MemKey.

Because that conversion is still awkward as it has to handle many not-quite-consistent name combinations, maybe we should then even make this explicit by giving UnaryVRRa and friends an optional "fp_mnemonic" operand, so that the mapping is fully explicit in the main .td file, e.g. like so:

  def WLDEB : UnaryVRRa<"wldeb", 0xE7C4, any_fpextend, v64db, v32sb, 2, 8, "ldebr">;
  def WFSQSB : UnaryVRRa<"wfsqsb", 0xE7CE, any_fsqrt, v32sb, v32sb, 2, 8, "sqebr">;


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76705/new/

https://reviews.llvm.org/D76705





More information about the llvm-commits mailing list