SuccessChanges

Summary

  1. [CodeEmitter] Support instruction widths > 64 bits (details)
  2. [CodeEmitter] Improve testing for APInt encoding (details)
  3. [ARM] Simplify and update vmla test. NFC (details)
  4. [SLP] limit vectorization of Constant subclasses (PR33958) (details)
Commit 60aadd19cbffc3793476a14d2e3529214119e2f5 by jmolloy
[CodeEmitter] Support instruction widths > 64 bits
Some VLIW instruction sets are Very Long Indeed. Using uint64_t
constricts the Inst encoding to 64 bits (naturally).
This change switches CodeEmitter to a mode that uses APInts when Inst's
bitwidth is > 64 bits (NFC for existing targets).
When Inst.BitWidth > 64 the prototype changes to:
  void TargetMCCodeEmitter::getBinaryCodeForInstr(const MCInst &MI,
                                               
SmallVectorImpl<MCFixup> &Fixups,
                                                 APInt &Inst,
                                                 APInt &Scratch,
                                                 const MCSubtargetInfo
&STI);
The Inst parameter returns the encoded instruction, the Scratch
parameter is used internally for manipulating operands and is exposed so
that the underlying storage can be reused between calls to
getBinaryCodeForInstr. The goal is to elide any APInt constructions that
we can.
Similarly the operand encoding prototype changes to:
  getMachineOpValue(const MCInst &MI, const MCOperand &MO, APInt &op,
SmallVectorImpl<MCFixup> &Fixups, const MCSubtargetInfo &STI);
That is, the operand is passed by reference as APInt rather than
returned as uint64_t.
To reiterate, this APInt mode is enabled only when Inst.BitWidth > 64,
so this change is NFC for existing targets.
llvm-svn: 371928
The file was addedllvm/test/TableGen/BigEncoder.td
The file was modifiedllvm/test/TableGen/RegisterEncoder.td
The file was modifiedllvm/utils/TableGen/CodeEmitterGen.cpp
Commit a088b95f89176b87553d68f3ffbe1f7cba4cefb5 by jmolloy
[CodeEmitter] Improve testing for APInt encoding
I missed Artem's comment in D67487 before committing.
Differential Revision: https://reviews.llvm.org/D67487
llvm-svn: 371929
The file was modifiedllvm/test/TableGen/BigEncoder.td
Commit 06b309d5274951a9c3c37598afece51b3948e2a4 by david.green
[ARM] Simplify and update vmla test. NFC
llvm-svn: 371930
The file was modifiedllvm/test/CodeGen/Thumb2/mve-vmla.ll
The file was modifiedllvm/test/CodeGen/Thumb2/mve-vmaxv.ll
Commit b6a0faaa0c793aede7911be241b1895a9ebea41c by spatel
[SLP] limit vectorization of Constant subclasses (PR33958)
This is a fix for: https://bugs.llvm.org/show_bug.cgi?id=33958
It seems universally true that we would not want to transform this kind
of sequence on any target, but if that's not correct, then we could view
this as a target-specific cost model problem. We could also white-list
ConstantInt, ConstantFP, etc. rather than blacklist Global and
ConstantExpr.
Differential Revision: https://reviews.llvm.org/D67362
llvm-svn: 371931
The file was modifiedllvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
The file was modifiedllvm/test/Transforms/SLPVectorizer/X86/consecutive-access.ll