[all-commits] [llvm/llvm-project] 25a150: Revert "[InlineCost] Check for conflicting target ...

Wed Sep 27 08:54:46 PDT 2023

  Branch: refs/heads/release/17.x
  Home:   https://github.com/llvm/llvm-project
  Commit: 25a150b830f6dd0dd8295fe93d0895f262a58592
      https://github.com/llvm/llvm-project/commit/25a150b830f6dd0dd8295fe93d0895f262a58592
  Author: Kazu Hirata <kazu at google.com>
  Date:   2023-09-27 (Wed, 27 Sep 2023)

  Changed paths:
    M llvm/lib/Analysis/InlineCost.cpp
    R llvm/test/Transforms/Inline/target-features-vs-alwaysinline.ll

  Log Message:
  -----------
  Revert "[InlineCost] Check for conflicting target attributes early"

This reverts commit d6f994acb3d545b80161e24ab742c9c69d4bbf33.

Several people have reported breakage resulting from this patch:

- https://github.com/llvm/llvm-project/issues/65152
- https://github.com/llvm/llvm-project/issues/65205

(cherry picked from commit b4301df61fc77a9d54ac236bc88742a731285f1c)

  Commit: 178cf5bc8732a010f02e9a262f08afc549a1bc1d
      https://github.com/llvm/llvm-project/commit/178cf5bc8732a010f02e9a262f08afc549a1bc1d
  Author: Takuya Shimizu <shimizu2486 at gmail.com>
  Date:   2023-09-27 (Wed, 27 Sep 2023)

  Changed paths:
    M clang/lib/Frontend/TextDiagnostic.cpp
    M clang/test/Misc/diag-style.cpp

  Log Message:
  -----------
  [clang][Diagnostics] Fix wrong line number display (#65238)

When the caret location is lower than the lowest source range, clang is
printing wrong line numbers. The first line number should consider caret
location line even when there are source ranges provided.

Current wrong line example: https://godbolt.org/z/aj4qEjzs4

(cherry picked from commit ef5217b3c0dcbb58927fe43400b6d1faa677bf98)

  Commit: 5f1fcc43e592871b3860760a4bed56cf1be5772f
      https://github.com/llvm/llvm-project/commit/5f1fcc43e592871b3860760a4bed56cf1be5772f
  Author: Antonio Frighetto <me at antoniofrighetto.com>
  Date:   2023-09-27 (Wed, 27 Sep 2023)

  Changed paths:
    M clang/lib/AST/ExprConstant.cpp
    A clang/test/SemaCXX/cxx2a-virtual-base-used.cpp

  Log Message:
  -----------
  [clang] Bail out when handling union access with virtual inheritance

An assertion issue that arose when handling union member access with
virtual base class has been addressed. As pointed out by @zygoloid,
there is no need for further derived-to-base analysis in this instance,
so we can bail out upon encountering a virtual base class. Minor
refinement on the function name as we might not be handling a union.

Reported-By: ormris

Fixes: https://github.com/llvm/llvm-project/issues/65982
(cherry picked from commit 660876a4019b81b5a7427a3dcec5ce8c39cd1ee0)

  Commit: 4362f3e4cf4804da015be58f5514cb3a59254d49
      https://github.com/llvm/llvm-project/commit/4362f3e4cf4804da015be58f5514cb3a59254d49
  Author: Antonio Frighetto <me at antoniofrighetto.com>
  Date:   2023-09-27 (Wed, 27 Sep 2023)

  Changed paths:
    M clang/test/SemaCXX/cxx2a-virtual-base-used.cpp

  Log Message:
  -----------
  [clang] Include `expected-no-diagnostics` in newly-added test (NFC)

(cherry picked from commit c990d9444350ef583c6d53e84d9c10cebbf65532)

  Commit: 773f136d6faa5b5120107cd5b79b16ee3a307d3a
      https://github.com/llvm/llvm-project/commit/773f136d6faa5b5120107cd5b79b16ee3a307d3a
  Author: Nikita Popov <npopov at redhat.com>
  Date:   2023-09-27 (Wed, 27 Sep 2023)

  Changed paths:
    M llvm/lib/Transforms/Scalar/SimpleLoopUnswitch.cpp
    M llvm/test/Transforms/SimpleLoopUnswitch/inject-invariant-conditions.ll

  Log Message:
  -----------
  [SimpleLoopUnswitch] Fix reversed branch during condition injection

The in-loop successor is only on the left after a potential condition
inversion. As we re-use the old condition as-is, we should also
reuse the old successors as-is.

Fixes https://github.com/llvm/llvm-project/issues/63962.

(cherry picked from commit afd7db48c55cb87566758e961f1ebac8af16b8bc)

  Commit: 2839aa915066531621ade9c976f0594b797c1b5c
      https://github.com/llvm/llvm-project/commit/2839aa915066531621ade9c976f0594b797c1b5c
  Author: Nikita Popov <npopov at redhat.com>
  Date:   2023-09-27 (Wed, 27 Sep 2023)

  Changed paths:
    M llvm/lib/Transforms/Scalar/SimpleLoopUnswitch.cpp
    A llvm/test/Transforms/SimpleLoopUnswitch/inject-invariant-conditions-exponential.ll
    M llvm/test/Transforms/SimpleLoopUnswitch/inject-invariant-conditions.ll

  Log Message:
  -----------
  [SimpleLoopUnswitch] Fix exponential unswitch

When unswitching via invariant condition injection, we currently
mark the condition in the old loop, so that it does not get
unswitched again. However, if there are multiple branches for
which conditions can be injected, then we can do that for both
the old and new loop. This means that the number of unswitches
increases exponentially.

Change the handling to be more similar to partial unswitching,
where we instead mark the whole loop, rather than a single
condition. This means that we will only generate a linear number
of loops.

TBH I think even that is still highly undesirable, and we should
probably be unswitching all candidates at the same time, so that
we end up with only two loops. But at least this mitigates the
worst case.

The test case is a reduced variant that generates 1700 lines of IR
without this patch and 290 with it.

Fixes https://github.com/llvm/llvm-project/issues/66868.

(cherry picked from commit 8362cae71b80bc43c8c680cdfb13c495705a622f)

  Commit: 17123a60b87c5c26b297be4eb31725eaf28c2194
      https://github.com/llvm/llvm-project/commit/17123a60b87c5c26b297be4eb31725eaf28c2194
  Author: Nikita Popov <npopov at redhat.com>
  Date:   2023-09-27 (Wed, 27 Sep 2023)

  Changed paths:
    A llvm/test/CodeGen/X86/stack-coloring-seh.ll

  Log Message:
  -----------
  [X86] Add test for #66984 (NFC)

(cherry picked from commit 8b4e29b35d21b079e8b30244cbbfc4d4bc4a29d4)

  Commit: 49e9ee1900803f3e6b4ce3b5c774d55e7ccbd262
      https://github.com/llvm/llvm-project/commit/49e9ee1900803f3e6b4ce3b5c774d55e7ccbd262
  Author: Nikita Popov <npopov at redhat.com>
  Date:   2023-09-27 (Wed, 27 Sep 2023)

  Changed paths:
    M llvm/lib/CodeGen/StackColoring.cpp
    R llvm/test/CodeGen/X86/stack-coloring-seh.ll
    A llvm/test/CodeGen/X86/stack-coloring-wineh.ll

  Log Message:
  -----------
  [StackColoring] Handle SEH catch object stack slots conservatively

The write to the SEH catch object happens before cleanuppads are
executed, while the first reference to the object will typically
be in a catchpad.

If we make use of first-use analysis, we may end up allocating
an alloca used inside the cleanuppad and the catch object at the
same stack offset, which would be incorrect.

https://reviews.llvm.org/D86673 was a previous attempt to fix it.
It used the heuristic "a slot loaded in a WinEH pad and never
written" to detect catch objects. However, because it checks
for more than one load (while probably more than zero was
intended), the fix does not actually work.

The general approach also seems dubious to me, so this patch
reverts that change entirely, and instead marks all catch object
slots as conservative (i.e. excluded from first-use analysis)
based on the WinEHFuncInfo. As far as I can tell we don't need
any heuristics here, we know exactly which slots are affected.

Fixes https://github.com/llvm/llvm-project/issues/66984.

(cherry picked from commit b3cb4f069c2cb99bdae68d6906156af20e76314f)

  Commit: 9678f11b057c1f33b9b714105e7c8e34f2f96bed
      https://github.com/llvm/llvm-project/commit/9678f11b057c1f33b9b714105e7c8e34f2f96bed
  Author: Nikita Popov <npopov at redhat.com>
  Date:   2023-09-27 (Wed, 27 Sep 2023)

  Changed paths:
    M llvm/lib/CodeGen/StackColoring.cpp
    M llvm/test/CodeGen/X86/stack-coloring-wineh.ll

  Log Message:
  -----------
  [StackColoring] Handle fixed object index

This is a followup to #66988. The implementation there did not
account for the possibility of the catch object frame index
referrring to a fixed object, which is the case on win64.

(cherry picked from commit aa70f4d8cf8f09a2997773156289b16d6a16ec01)

Compare: https://github.com/llvm/llvm-project/compare/481358974fb0...9678f11b057c