SuccessChanges

Summary

  1. [RISCV] Match vmslt(u).vx intrinsics with a small immediate to vmsle(u).vx. (details)
  2. [SLP] delete unused pairwise reduction option (details)
  3. [RISCV] Don't print zext.b alias. (details)
  4. [NFC] Fix -Wrange-loop-analysis warnings. (details)
  5. [LoopNest] Allow empty basic blocks without loops (details)
  6. [mlir] Gen removeAttr methods with tablegen (details)
  7. [RISCV] Don't parse 'vmsltu.vi v0, v1, 0' as 'vmsleu.vi v0, v1, -1' (details)
Commit c707716c049cd46bd89da102cf9444462487b490 by craig.topper
[RISCV] Match vmslt(u).vx intrinsics with a small immediate to vmsle(u).vx.

There are vmsle(u).vx and vmsle(u).vi instructions, but there is
only vmslt(u).vx and no vmslt(u).vi. vmslt(u).vi can be emulated
for some immediates by decrementing the immediate and using vmsle(u).vi.

To avoid the user needing to know about this, this patch does this
conversion.

The assembler does the same thing for vmslt(u).vi and vmsge(u).vi
pseudoinstructions. There is no vmsge(u).vx intrinsic or
instruction so this patch is limited to vmslt(u).

Reviewed By: frasercrmck

Differential Revision: https://reviews.llvm.org/D94070
The file was modifiedllvm/test/CodeGen/RISCV/rvv/vmsltu-rv32.ll
The file was modifiedllvm/test/CodeGen/RISCV/rvv/vmslt-rv32.ll
The file was modifiedllvm/test/CodeGen/RISCV/rvv/vmsltu-rv64.ll
The file was modifiedllvm/test/CodeGen/RISCV/rvv/vmslt-rv64.ll
The file was modifiedllvm/lib/Target/RISCV/RISCVInstrInfoVPseudos.td
Commit 3b8b2c7da2efb88d9f13e911e383af430ab463ef by spatel
[SLP] delete unused pairwise reduction option

SLP tries to model 2 forms of vector reductions: pairwise and splitting.
From the cost model code comments, those are defined using an example as:

  /// Pairwise:
  ///  (v0, v1, v2, v3)
  ///  ((v0+v1), (v2+v3), undef, undef)
  /// Split:
  ///  (v0, v1, v2, v3)
  ///  ((v0+v2), (v1+v3), undef, undef)

I don't know the full history of this functionality, but it was partly
added back in D29402. There are apparently no users at this point (no
regression tests change). X86 might have managed to work-around the need
for this through cost model and codegen improvements.

Removing this code makes it easier to continue the work that was started
in D87416 / D88193. The alternative -- if there is some target that is
silently using this option -- is to move this logic into LoopUtils. We
have related/duplicate functionality there via llvm::createTargetReduction().

Differential Revision: https://reviews.llvm.org/D93860
The file was modifiedllvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
Commit 249d7de1190f50178181d2477aa661cd252e294c by craig.topper
[RISCV] Don't print zext.b alias.

This alias for andi x, 255 was recently added to the spec. If we
print it, code we output can't be compiled with -fno-integrated-as
unless the GNU assembler is also a version that supports alias.

Reviewed By: lenary

Differential Revision: https://reviews.llvm.org/D93826
The file was modifiedllvm/test/CodeGen/RISCV/rv64Zbbp.ll
The file was modifiedllvm/test/MC/RISCV/rv32i-aliases-valid.s
The file was modifiedllvm/test/MC/RISCV/rv64b-aliases-valid.s
The file was modifiedllvm/lib/Target/RISCV/RISCVInstrInfo.td
The file was modifiedllvm/test/CodeGen/RISCV/alu8.ll
The file was modifiedllvm/test/MC/RISCV/rv32b-aliases-valid.s
The file was modifiedllvm/test/CodeGen/RISCV/calling-conv-ilp32-ilp32f-ilp32d-common.ll
The file was modifiedllvm/test/CodeGen/RISCV/atomic-cmpxchg.ll
The file was modifiedllvm/test/CodeGen/RISCV/sext-zext-trunc.ll
The file was modifiedllvm/test/CodeGen/RISCV/rv32Zbbp.ll
The file was modifiedllvm/test/CodeGen/RISCV/bswap-ctlz-cttz-ctpop.ll
The file was modifiedllvm/test/CodeGen/RISCV/calling-conv-lp64-lp64f-lp64d-common.ll
The file was modifiedllvm/test/CodeGen/RISCV/calling-conv-sext-zext.ll
The file was modifiedllvm/test/CodeGen/RISCV/atomic-rmw.ll
The file was modifiedllvm/test/MC/RISCV/rv64i-aliases-valid.s
Commit 7afd5cfbc757b004cba99d234df4e76b06956b2d by joker.eph
[NFC] Fix -Wrange-loop-analysis warnings.

Remove unnecessary `&` from loop variables.

Fix warnings: "loop variable is always a copy because the range does not
return a reference".

```
[240/2862] Building CXX object tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/TypeDefGen.cpp.o
llvm-project/mlir/tools/mlir-tblgen/TypeDefGen.cpp:50:25: warning: loop variable 'typeDef' is always a copy because the range of type 'llvm::iterator_range<llvm::mapped_iterator<std::__1::__wrap_iter<llvm::Record **>, (lambda at llvm-project/mlir/tools/mlir-tblgen/TypeDefGen.cpp:40:16), mlir::tblgen::TypeDef> >' does not return a reference [-Wrange-loop-analysis]
    for (const TypeDef &typeDef : defs)
                        ^
llvm-project/mlir/tools/mlir-tblgen/TypeDefGen.cpp:50:10: note: use non-reference type 'mlir::tblgen::TypeDef'
    for (const TypeDef &typeDef : defs)
         ^~~~~~~~~~~~~~~~~~~~~~~~
llvm-project/mlir/tools/mlir-tblgen/TypeDefGen.cpp:64:23: warning: loop variable 'typeDef' is always a copy because the range of type 'llvm::iterator_range<llvm::mapped_iterator<std::__1::__wrap_iter<llvm::Record **>, (lambda at llvm-project/mlir/tools/mlir-tblgen/TypeDefGen.cpp:40:16), mlir::tblgen::TypeDef> >' does not return a reference [-Wrange-loop-analysis]
  for (const TypeDef &typeDef : defs)
                      ^
llvm-project/mlir/tools/mlir-tblgen/TypeDefGen.cpp:64:8: note: use non-reference type 'mlir::tblgen::TypeDef'
  for (const TypeDef &typeDef : defs)
       ^~~~~~~~~~~~~~~~~~~~~~~~
2 warnings generated.

[1934/2862] Building CXX object tools...Files/toyc-ch4.dir/mlir/MLIRGen.cpp.o
llvm-project/mlir/examples/toy/Ch4/mlir/MLIRGen.cpp:139:22: warning: loop variable 'name_value' is always a copy because the range of type 'detail::zippy<detail::zip_shortest, ArrayRef<unique_ptr<VariableExprAST, default_delete<VariableExprAST> > > &, MutableArrayRef<BlockArgument> >' does not return a reference [-Wrange-loop-analysis]
    for (const auto &name_value :
                     ^
llvm-project/mlir/examples/toy/Ch4/mlir/MLIRGen.cpp:139:10: note: use non-reference type 'std::__1::tuple<const std::__1::unique_ptr<toy::VariableExprAST, std::__1::default_delete<toy::VariableExprAST> > &, mlir::BlockArgument &>'
    for (const auto &name_value :
         ^~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.

[1940/2862] Building CXX object tools...Files/toyc-ch5.dir/mlir/MLIRGen.cpp.o
llvm-project/mlir/examples/toy/Ch5/mlir/MLIRGen.cpp:139:22: warning: loop variable 'name_value' is always a copy because the range of type 'detail::zippy<detail::zip_shortest, ArrayRef<unique_ptr<VariableExprAST, default_delete<VariableExprAST> > > &, MutableArrayRef<BlockArgument> >' does not return a reference [-Wrange-loop-analysis]
    for (const auto &name_value :
                     ^
llvm-project/mlir/examples/toy/Ch5/mlir/MLIRGen.cpp:139:10: note: use non-reference type 'std::__1::tuple<const std::__1::unique_ptr<toy::VariableExprAST, std::__1::default_delete<toy::VariableExprAST> > &, mlir::BlockArgument &>'
    for (const auto &name_value :
         ^~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
```

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D94003
The file was modifiedmlir/examples/toy/Ch5/mlir/MLIRGen.cpp
The file was modifiedmlir/examples/toy/Ch2/mlir/MLIRGen.cpp
The file was modifiedmlir/examples/toy/Ch6/mlir/MLIRGen.cpp
The file was modifiedmlir/tools/mlir-tblgen/TypeDefGen.cpp
The file was modifiedmlir/examples/toy/Ch4/mlir/MLIRGen.cpp
The file was modifiedmlir/examples/toy/Ch7/mlir/Dialect.cpp
The file was modifiedmlir/examples/toy/Ch3/mlir/MLIRGen.cpp
The file was modifiedmlir/examples/toy/Ch7/mlir/MLIRGen.cpp
Commit 601636de98061b53242b598fc2354905c8efbfb8 by whitneyt
[LoopNest] Allow empty basic blocks without loops

Addressed Florian's post commit review comments:
1. included STLExtras.h
2. changed std::all_of to llvm::all_of

Differential Revision: https://reviews.llvm.org/D93665
The file was modifiedllvm/include/llvm/Analysis/LoopNestAnalysis.h
Commit 86d68e288585964546d6382ecf71dcce10d018b7 by joker.eph
[mlir] Gen removeAttr methods with tablegen

If an operation defines an optional attribute (OptionalAttr or
UnitAttr), transformations may wish to remove these attributes while
maintaining invariants established by the operation. Currently, the only
way to do this is by calling `Operation::removeAttr("attrName")`, which
requires developers to know the exact name of the attribute used by
table-gen. Furthermore, if the attribute name changes, this won't be
detected at compile time. Instead, `removeAttr` would return an empty
attribute and no errors would be raised, unless the caller checks for
the returned value.

This patch adds table gen support for generating `remove<AttrName>Attr`
methods for OptionalAttributes defined by operations.

Implementation choice: to preserve camelCase for the method's name, the
first character of an attribute called `myAttr` is changed to upper case
in order to preserve the coding style, so the final method would be
called `removeMyAttr`.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D93903
The file was modifiedmlir/test/mlir-tblgen/op-attribute.td
The file was modifiedmlir/tools/mlir-tblgen/OpDefinitionsGen.cpp
The file was modifiedmlir/test/mlir-tblgen/op-decl.td
Commit 210bc3dc0eb3550fd99158e5747619ad9e91c548 by craig.topper
[RISCV] Don't parse 'vmsltu.vi v0, v1, 0' as 'vmsleu.vi v0, v1, -1'

vmsltu.vi v0, v1, 0 is always false there is no unsigned number
less than 0. vmsleu.vi v0, v1, -1 on the other hand is always true
since -1 will be considered unsigned max and all numbers are <=
unsigned max.

A similar problem exists for vmsgeu.vi v0, v1, 0 which is always true,
but becomes vmsgtu.vi v0, v1, -1 which is always false.

To match the GNU assembler we'll emit vmsne.vv and vmseq.vv with
the same register for these cases instead.

I'm using AsmParserOnly pseudo instructions here because we can't
match an explicit immediate in an InstAlias. And we can't use a
AsmOperand for the zero because the output we want doesn't use an
immediate so there's nowhere to name the AsmOperand we want to use.

To keep the implementations similar I'm also handling signed with
pseudo instructions even though they don't have this issue. This
way we can avoid the special renderMethod that decremented by 1 so
the immediate we see for the pseudo instruction in processInstruction
is 0 and not -1. Another option might have been to have a different
simm5_plus1 operand for the unsigned case or just live with the
immediate being pre-decremented. I felt this way was clearer, but I'm
open to other opinions.

Reviewed By: frasercrmck

Differential Revision: https://reviews.llvm.org/D94035
The file was modifiedllvm/lib/Target/RISCV/RISCVInstrInfoV.td
The file was modifiedllvm/test/MC/RISCV/rvv/compare.s
The file was modifiedllvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp