[all-commits] [llvm/llvm-project] 46a1b0: [AArch64] Legalize horizontal fmax/fmin reductions...

Raul Tambre via All-commits all-commits at lists.llvm.org
Mon Mar 8 20:17:11 PST 2021


  Branch: refs/heads/release/12.x
  Home:   https://github.com/llvm/llvm-project
  Commit: 46a1b0655666e21c56fa79560e9baee87405d4f4
      https://github.com/llvm/llvm-project/commit/46a1b0655666e21c56fa79560e9baee87405d4f4
  Author: LemonBoy <thatlemon at gmail.com>
  Date:   2021-03-08 (Mon, 08 Mar 2021)

  Changed paths:
    M llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
    M llvm/test/CodeGen/AArch64/vecreduce-fmax-legalization.ll
    M llvm/test/CodeGen/AArch64/vecreduce-fmin-legalization.ll

  Log Message:
  -----------
  [AArch64] Legalize horizontal fmax/fmin reductions on f16 vectors

Expand the horizontal reduction during the instruction selection phase, but only if the target doesn't support the full fp16 instruction set.

Fixes https://bugs.llvm.org/show_bug.cgi?id=49401

Reviewed By: aemerson

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

(cherry picked from commit 8725b24c6d4abaa97425e704652a13dacb35fe3f)


  Commit: f8b32989241cca87a8690c8cc404f06ce1f90e4c
      https://github.com/llvm/llvm-project/commit/f8b32989241cca87a8690c8cc404f06ce1f90e4c
  Author: Nathan James <n.james93 at hotmail.co.uk>
  Date:   2021-03-08 (Mon, 08 Mar 2021)

  Changed paths:
    M clang-tools-extra/docs/ReleaseNotes.rst
    M clang-tools-extra/docs/clang-tidy/checks/readability-deleted-default.rst

  Log Message:
  -----------
  [clang-tidy] Deprecate readability-deleted-default check

... For removal in next release cycle.
The clang warning that does the same thing is enabled by default and typically emits better diagnostics making this check surplus to requirements.

Reviewed By: aaron.ballman

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

(cherry picked from commit 19aefd2d5dc3a8d3b8e81219973828170b7fcd2c)


  Commit: a123beacce408af8c2de1f39d522ac6b6c4b5d1b
      https://github.com/llvm/llvm-project/commit/a123beacce408af8c2de1f39d522ac6b6c4b5d1b
  Author: Juneyoung Lee <aqjune at gmail.com>
  Date:   2021-03-08 (Mon, 08 Mar 2021)

  Changed paths:
    M llvm/lib/Transforms/Vectorize/LoopVectorizationPlanner.h
    M llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
    M llvm/test/Transforms/LoopVectorize/X86/masked_load_store.ll
    M llvm/test/Transforms/LoopVectorize/X86/x86-interleaved-accesses-masked-group.ll
    M llvm/test/Transforms/LoopVectorize/if-conversion-nest.ll
    M llvm/test/Transforms/LoopVectorize/if-pred-non-void.ll
    M llvm/test/Transforms/LoopVectorize/if-reduction.ll
    A llvm/test/Transforms/LoopVectorize/pr48832.ll
    M llvm/test/Transforms/LoopVectorize/reduction-inloop-pred.ll
    M llvm/test/Transforms/LoopVectorize/reduction-inloop.ll

  Log Message:
  -----------
  [LoopVectorize] Fix VPRecipeBuilder::createEdgeMask to correctly generate the mask

This patch fixes pr48832 by correctly generating the mask when a poison value is involved.

Consider this CFG (which is a part of the input):

```
for.body:                                         ; preds = %for.cond
  br i1 true, label %cond.false, label %land.rhs

land.rhs:                                         ; preds = %for.body
  br i1 poison, label %cond.end, label %cond.false

cond.false:                                       ; preds = %for.body, %land.rhs
  br label %cond.end

cond.end:                                         ; preds = %land.rhs, %cond.false
  %cond = phi i32 [ 0, %cond.false ], [ 1, %land.rhs ]

```

The path for.body -> land.rhs -> cond.end should be taken when 'select i1 false, i1 poison, i1 false' holds (which means it's never taken); but VPRecipeBuilder::createEdgeMask was emitting 'and i1 false, poison' instead.
The former one successfully blocks poison propagation whereas the latter one doesn't, making the condition poison and thus causing the miscompilation.

SimplifyCFG has a similar bug (which didn't expose a real-world bug yet), and a patch for this is also ongoing (see https://reviews.llvm.org/D95026).

Reviewed By: bjope

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

(cherry picked from commit ed253ef77248d91a15b3a1aa36c0b74bed8ec8af)


  Commit: bff59aca162ef16d7634dc9df39f1f3af31ecb93
      https://github.com/llvm/llvm-project/commit/bff59aca162ef16d7634dc9df39f1f3af31ecb93
  Author: Craig Topper <craig.topper at sifive.com>
  Date:   2021-03-08 (Mon, 08 Mar 2021)

  Changed paths:
    M llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp
    A llvm/test/CodeGen/X86/pr49393.ll

  Log Message:
  -----------
  [TargetLowering] Use HandleSDNodes to prevent nodes from being deleted by recursive calls in getNegatedExpression.

For binary or ternary ops we call getNegatedExpression multiple
times and then compare costs. While we're doing this we need to
hold a node from the first call across the second call, but its
not yet attached to the DAG. Its possible the second call creates
an identical node and then decides it didn't need it so will try
to delete it if it has no uses. This can cause a reference to the
node we're holding further up the call stack to become invalidated.

To prevent this, we can use a HandleSDNode to artifically give
the node a use without connecting it to the DAG.

I've used a std::list of HandleSDNodes so we can create handles
only when we have a node to hold. HandleSDNode does not have
default constructor and cannot be copied or moved.

Fixes PR49393.

Reviewed By: spatel

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

(cherry picked from commit 74e6030bcbcc8e628f9a99a424342a0c656456f9)


  Commit: 15d1ee36720ff24323f55452ae3cfb63f318c3f3
      https://github.com/llvm/llvm-project/commit/15d1ee36720ff24323f55452ae3cfb63f318c3f3
  Author: Raul Tambre <raul.tambre at cleveron.com>
  Date:   2021-03-08 (Mon, 08 Mar 2021)

  Changed paths:
    M compiler-rt/lib/builtins/CMakeLists.txt

  Log Message:
  -----------
  [CMake][compiler-rt] Use copying instead of symlinking for LSE builtins on non-Unix-likes

As reported in D93278 post-review symlinking requires privilege escalation on Windows.
Copying is functionally same, so fallback to it for systems that aren't Unix-like.
This is similar to the solution in AddLLVM.cmake.

Reviewed By: ikudrin

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

(cherry picked from commit ba860963b156db3b653c67ef044df877f3cea9cc)


Compare: https://github.com/llvm/llvm-project/compare/d24e102ba266...15d1ee36720f


More information about the All-commits mailing list