[all-commits] [llvm/llvm-project] 5d8390: Temporarily disable test on Fuchsia

Wed Jan 22 23:23:37 PST 2025

  Branch: refs/heads/users/MaskRay/spr/driver-fno-plt-warn-for-non-elf
  Home:   https://github.com/llvm/llvm-project
  Commit: 5d8390d48e5c03235b3c83748e4a2eec0a19ae65
      https://github.com/llvm/llvm-project/commit/5d8390d48e5c03235b3c83748e4a2eec0a19ae65
  Author: mingmingl <mingmingl at google.com>
  Date:   2025-01-22 (Wed, 22 Jan 2025)

  Changed paths:
    M llvm/test/CodeGen/X86/jump-table-partition.ll

  Log Message:
  -----------
  Temporarily disable test on Fuchsia

  Commit: c3dfd34e54c1cb9e0e6c7472a6d30d03a63f6f0a
      https://github.com/llvm/llvm-project/commit/c3dfd34e54c1cb9e0e6c7472a6d30d03a63f6f0a
  Author: Heejin Ahn <aheejin at gmail.com>
  Date:   2025-01-22 (Wed, 22 Jan 2025)

  Changed paths:
    M llvm/lib/Target/WebAssembly/WebAssemblyCFGStackify.cpp
    M llvm/lib/Target/WebAssembly/WebAssemblyInstrControl.td
    M llvm/test/CodeGen/WebAssembly/cfg-stackify-eh.ll
    M llvm/test/CodeGen/WebAssembly/exception-legacy.mir
    M llvm/test/CodeGen/WebAssembly/exception.ll

  Log Message:
  -----------
  [WebAssembly] Add unreachable before catch destinations (#123915)

When `try_table`'s catch clause's destination has a return type, as in
the case of catch with a concrete tag, catch_ref, and catch_all_ref. For
example:
```wasm
block exnref
  try_table (catch_all_ref 0)
    ...
  end_try_table
end_block
... use exnref ...
```

This code is not valid because the block's body type is not exnref. So
we add an unreachable after the 'end_try_table' to make the code valid
here:
```wasm
block exnref
  try_table (catch_all_ref 0)
    ...
  end_try_table
  unreachable                    ;; Newly added
end_block
```
Because 'unreachable' is a terminator we also need to split the BB.

---

We need to handle the same thing for unwind mismatch handling. In the
code below, we create a "trampoline BB" that will be the destination for
the nested `try_table`~`end_try_table` added to fix a unwind mismatch:
```wasm
try_table (catch ... )
  block exnref
    ...
    try_table (catch_all_ref N)
      some code
    end_try_table
    ...
  end_block                      ;; Trampoline BB
  throw_ref
end_try_table
```
While the `block` added for the trampoline BB has the return type
`exnref`, its body, which contains the nested `try_table` and other
code, wouldn't have the `exnref` return type. Most times it didn't
become a problem because the block's body ended with something like `br`
or `return`, but that may not always be the case, especially when there
is a loop. So we add an `unreachable` to make the code valid here too:
```wasm
try_table (catch ... )
  block exnref
    ...
    try_table (catch_all_ref N)
      some code
    end_try_table
    ...
    unreachable                  ;; Newly added
  end_block                      ;; Trampoline BB
  throw_ref
end_try_table
```
In this case we just append the `unreachable` at the end of the layout
predecessor BB. (This was tricky to do in the first (non-mismatch) case
because there `end_try_table` and `end_block` were added in the
beginning of an EH pad in `placeTryTableMarker` and moving
`end_try_table` and the new `unreachable` to the previous BB caused
other problems.)

---

This adds many `unreaachable`s to the output, but this adds
`unreachable` to only a few places to see if this is working. The
FileCheck lines in `exception.ll` and `cfg-stackify-eh.ll` are already
heavily redacted to only leave important control-flow instructions, so I
don't think it's worth adding `unreachable`s everywhere.

  Commit: ba174855203403f6c3e2a46bdd79dbb3e27ac6a4
      https://github.com/llvm/llvm-project/commit/ba174855203403f6c3e2a46bdd79dbb3e27ac6a4
  Author: Nathan Ridge <zeratul976 at hotmail.com>
  Date:   2025-01-23 (Thu, 23 Jan 2025)

  Changed paths:
    M clang/docs/ReleaseNotes.rst
    M clang/lib/Sema/SemaCodeComplete.cpp
    M clang/test/CodeCompletion/member-access.cpp

  Log Message:
  -----------
  [clang][CodeComplete] Use HeuristicResolver to resolve DependentNameTypes (#123818)

Fixes https://github.com/clangd/clangd/issues/1249

  Commit: 220004d2f8692e3a224dc75f7a7c6001711d3d58
      https://github.com/llvm/llvm-project/commit/220004d2f8692e3a224dc75f7a7c6001711d3d58
  Author: Alan Li <me at alanli.org>
  Date:   2025-01-22 (Wed, 22 Jan 2025)

  Changed paths:
    M llvm/lib/CodeGen/GlobalISel/CSEInfo.cpp
    M llvm/unittests/CodeGen/GlobalISel/CSETest.cpp

  Log Message:
  -----------
  [GISel] Add more FP opcodes to CSE (#123949)

Resubmit, previously PR has compilation issues.

  Commit: 3fb8c5b43195d6e11ff0557d07e75700343d369f
      https://github.com/llvm/llvm-project/commit/3fb8c5b43195d6e11ff0557d07e75700343d369f
  Author: mconst <mconst at gmail.com>
  Date:   2025-01-23 (Thu, 23 Jan 2025)

  Changed paths:
    M llvm/lib/Target/X86/X86FrameLowering.cpp
    M llvm/test/CodeGen/X86/stack-clash-extra-huge.ll
    M llvm/test/CodeGen/X86/stack-clash-huge.ll

  Log Message:
  -----------
  [X86] Fix invalid instructions on x32 with large stack frames (#124041)

`X86FrameLowering::emitSPUpdate()` assumes that 64-bit targets use a
64-bit stack pointer, but that's not true on x32.
When checking the stack pointer size, we need to look at
`Uses64BitFramePtr` rather than `Is64Bit`. This avoids generating
invalid instructions like `add esp, rcx`.

For impossibly-large stack frames (4 GiB or larger with a 32-bit stack
pointer), we were also generating invalid instructions like `mov eax,
5000000000`. The inline stack probe code already had a check for that
situation; I've moved the check into `emitSPUpdate()`, so any attempt to
allocate a 4 GiB stack frame with a 32-bit stack pointer will now trap
rather than adjusting ESP by the wrong amount. This also fixes the
"can't have 32-bit 16GB stack frame" assertion, which used to be
triggerable by user code but is now correct.

To help catch situations like this in the future, I've added
`-verify-machineinstrs` to the stack clash tests that generate large
stack frames.

This fixes the expensive-checks buildbot failure caused by #113219.

  Commit: 45665f23c6872164e481a4b5ff7363b87912c27b
      https://github.com/llvm/llvm-project/commit/45665f23c6872164e481a4b5ff7363b87912c27b
  Author: Fangrui Song <i at maskray.me>
  Date:   2025-01-22 (Wed, 22 Jan 2025)

  Changed paths:
    M clang/docs/ReleaseNotes.rst
    M clang/lib/Driver/ToolChains/Clang.cpp
    M clang/lib/Sema/SemaCodeComplete.cpp
    M clang/test/CodeCompletion/member-access.cpp
    M clang/test/Driver/fno-plt.c
    M llvm/lib/CodeGen/GlobalISel/CSEInfo.cpp
    M llvm/lib/Target/WebAssembly/WebAssemblyCFGStackify.cpp
    M llvm/lib/Target/WebAssembly/WebAssemblyInstrControl.td
    M llvm/lib/Target/X86/X86FrameLowering.cpp
    M llvm/test/CodeGen/WebAssembly/cfg-stackify-eh.ll
    M llvm/test/CodeGen/WebAssembly/exception-legacy.mir
    M llvm/test/CodeGen/WebAssembly/exception.ll
    M llvm/test/CodeGen/X86/jump-table-partition.ll
    M llvm/test/CodeGen/X86/stack-clash-extra-huge.ll
    M llvm/test/CodeGen/X86/stack-clash-huge.ll
    M llvm/unittests/CodeGen/GlobalISel/CSETest.cpp

  Log Message:
  -----------
  .

Created using spr 1.3.5-bogner

Compare: https://github.com/llvm/llvm-project/compare/a38b6aecebba...45665f23c687

To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications