[all-commits] [llvm/llvm-project] 77e448: [NFC][InstCombine] Add shift amount reassociation ...

[Hans via All-commits]

  Branch: refs/heads/release/10.x
  Home:   https://github.com/llvm/llvm-project
  Commit: 77e448c0d3a87e7944381d7d53e55c997c8b936a
      https://github.com/llvm/llvm-project/commit/77e448c0d3a87e7944381d7d53e55c997c8b936a
  Author: Roman Lebedev <lebedev.ri at gmail.com>
  Date:   2020-02-27 (Thu, 27 Feb 2020)

  Changed paths:
    M llvm/test/Transforms/InstCombine/shift-amount-reassociation.ll

  Log Message:
  -----------
  [NFC][InstCombine] Add shift amount reassociation miscompile example from PR44802

https://bugs.llvm.org/show_bug.cgi?id=44802
(cherry picked from commit 425ef999385058143bb927aefe81daddcd43f623)


  Commit: f115a88191c3dc80c5140fbbf63f74ca77fcc74b
      https://github.com/llvm/llvm-project/commit/f115a88191c3dc80c5140fbbf63f74ca77fcc74b
  Author: Roman Lebedev <lebedev.ri at gmail.com>
  Date:   2020-02-27 (Thu, 27 Feb 2020)

  Changed paths:
    M llvm/lib/Transforms/InstCombine/InstCombineShifts.cpp
    M llvm/test/Transforms/InstCombine/shift-amount-reassociation.ll

  Log Message:
  -----------
  [InstCombine] reassociateShiftAmtsOfTwoSameDirectionShifts(): fix miscompile (PR44802)

As input, we have the following pattern:
  Sh0 (Sh1 X, Q), K
We want to rewrite that as:
  Sh x, (Q+K)  iff (Q+K) u< bitwidth(x)
While we know that originally (Q+K) would not overflow
(because  2 * (N-1) u<= iN -1), we may have looked past extensions of
shift amounts. so it may now overflow in smaller bitwidth.

To ensure that does not happen, we need to ensure that the total maximal
shift amount is still representable in that smaller bitwidth.
If the overflow would happen, (Q+K) u< bitwidth(x) check would be bogus.

https://bugs.llvm.org/show_bug.cgi?id=44802
(cherry picked from commit 781d077afb0ed9771c513d064c40170c1ccd21c9)


  Commit: ac293ede5e62cfc569f2d5d8f4667e6188afced0
      https://github.com/llvm/llvm-project/commit/ac293ede5e62cfc569f2d5d8f4667e6188afced0
  Author: Roman Lebedev <lebedev.ri at gmail.com>
  Date:   2020-02-27 (Thu, 27 Feb 2020)

  Changed paths:
    M llvm/test/Transforms/InstCombine/shift-amount-reassociation-in-bittest.ll

  Log Message:
  -----------
  [NFC][InstCombine] Add shift amount reassociation in bittest miscompile example from PR44802

https://bugs.llvm.org/show_bug.cgi?id=44802
(cherry picked from commit 6f807ca00d951d3e74f7ea4fe1daa8e3560f4c0d)


  Commit: b2b41bc3b51a083fb9e36e50d0131dfbd79e00ce
      https://github.com/llvm/llvm-project/commit/b2b41bc3b51a083fb9e36e50d0131dfbd79e00ce
  Author: Roman Lebedev <lebedev.ri at gmail.com>
  Date:   2020-02-27 (Thu, 27 Feb 2020)

  Changed paths:
    M llvm/lib/Transforms/InstCombine/InstCombineCompares.cpp
    M llvm/test/Transforms/InstCombine/shift-amount-reassociation-in-bittest.ll

  Log Message:
  -----------
  [InstCombine] foldShiftIntoShiftInAnotherHandOfAndInICmp(): fix miscompile (PR44802)

Much like with reassociateShiftAmtsOfTwoSameDirectionShifts(),
as input, we have the following pattern:
  icmp eq/ne (and ((x shift Q), (y oppositeshift K))), 0
We want to rewrite that as:
  icmp eq/ne (and (x shift (Q+K)), y), 0  iff (Q+K) u< bitwidth(x)

While we know that originally (Q+K) would not overflow
(because  2 * (N-1) u<= iN -1), we may have looked past extensions of
shift amounts. so it may now overflow in smaller bitwidth.

To ensure that does not happen, we need to ensure that the total maximal
shift amount is still representable in that smaller bitwidth.
If the overflow would happen, (Q+K) u< bitwidth(x) check would be bogus.

https://bugs.llvm.org/show_bug.cgi?id=44802
(cherry picked from commit 2855c8fed9326ec44526767f1596a4fe4e55dc70)


  Commit: 38ee10d08cb5982bfc02dc4eea9a22743dccc6b6
      https://github.com/llvm/llvm-project/commit/38ee10d08cb5982bfc02dc4eea9a22743dccc6b6
  Author: Hans Wennborg <hans at chromium.org>
  Date:   2020-02-27 (Thu, 27 Feb 2020)

  Changed paths:
    M clang/lib/Driver/ToolChains/Darwin.cpp
    M clang/test/Driver/darwin-ld-platform-version-ios.c
    M clang/test/Driver/darwin-ld-platform-version-macos.c
    M clang/test/Driver/darwin-ld-platform-version-tvos.c
    M clang/test/Driver/darwin-ld-platform-version-watchos.c

  Log Message:
  -----------
  [driver][darwin] Don't use -platform_version flag by default (PR44813)

The code in llvmorg-10-init-12188-g25ce33a6e4f is a breaking change for
users of older linkers who don't pass a version parameter, which
prevents a drop-in clang upgrade. Old tools can't know about what future
tools will do, so as a general principle the burden should be new tools
to be compatible by default. Also, for comparison, none of the other
tests of Version within AddLinkArgs add any new behaviors unless the
version is explicitly specified. Therefore, this patch changes the
-platform_version behavior from opt-out to opt-in.

Patch by David Major!

Differential revision: https://reviews.llvm.org/D74784

(cherry picked from commit 5122e828701c88f8d53ee881bc68f3904454d154)


Compare: https://github.com/llvm/llvm-project/compare/3b6f4c544be4...38ee10d08cb5