Skip to content

cowait #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Draft
wants to merge 14 commits into
base: main
Choose a base branch
from
Draft

cowait #1

wants to merge 14 commits into from

Conversation

@vtjnash
Copy link
Owner

@vtjnash vtjnash commented Jun 25, 2025 •
edited
Loading

TODO:

  • Document clearly that std::promise must call set_value only from a callback (never from another thread) and/or add the necessary memory barriers to make it okay
  • Consider having promises created by TaskDispatcher so that a TaskDispatcher can define the API (all virtual and/or templated)
  • Consider making wait_until friends with future
  • Consider adding TaskDispatcher.async and future.then to the APIs
  • Considering making data a std::conditional(is_default_constructable(T), T, std::unique_ptr<T>)

@vtjnash vtjnash force-pushed the jn/cowait-jit branch 2 times, most recently from 6b5161f to 3af5c37 Compare August 19, 2025 15:13
vtjnash pushed a commit that referenced this pull request Aug 20, 2025
@anutosh491
[lldb] Fix error : unknown error while starting lldb's C/C++ repl (ll…
00ffd8b 
…vm#153560)

Fixes llvm#153157

The proposed solution has been discussed here
(llvm#153157 (comment))

This is what we would be seeing now 

```
base) anutosh491@Anutoshs-MacBook-Air bin % ./lldb /Users/anutosh491/work/xeus-cpp/a.out
(lldb) target create "/Users/anutosh491/work/xeus-cpp/a.out"
Current executable set to '/Users/anutosh491/work/xeus-cpp/a.out' (arm64).
(lldb) b main
Breakpoint 1: where = a.out`main, address = 0x0000000100003f90
(lldb) r
Process 71227 launched: '/Users/anutosh491/work/xeus-cpp/a.out' (arm64)
Process 71227 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x0000000100003f90 a.out`main
a.out`main:
->  0x100003f90 <+0>:  sub    sp, sp, #0x10
    0x100003f94 <+4>:  str    wzr, [sp, #0xc]
    0x100003f98 <+8>:  str    w0, [sp, #0x8]
    0x100003f9c <+12>: str    x1, [sp]
(lldb) expression --repl -l c -- 
  1> 1 + 1
(int) $0 = 2
  2> 2 + 2
(int) $1 = 4
```

```
base) anutosh491@Anutoshs-MacBook-Air bin % ./lldb /Users/anutosh491/work/xeus-cpp/a.out
(lldb) target create "/Users/anutosh491/work/xeus-cpp/a.out"
Current executable set to '/Users/anutosh491/work/xeus-cpp/a.out' (arm64).
(lldb) b main
Breakpoint 1: where = a.out`main, address = 0x0000000100003f90
(lldb) r
Process 71355 launched: '/Users/anutosh491/work/xeus-cpp/a.out' (arm64)
Process 71355 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x0000000100003f90 a.out`main
a.out`main:
->  0x100003f90 <+0>:  sub    sp, sp, #0x10
    0x100003f94 <+4>:  str    wzr, [sp, #0xc]
    0x100003f98 <+8>:  str    w0, [sp, #0x8]
    0x100003f9c <+12>: str    x1, [sp]
(lldb) expression --repl -l c -- 3 + 3
Warning: trailing input is ignored in --repl mode
  1> 1 + 1
(int) $0 = 2
```
vtjnash pushed a commit that referenced this pull request Aug 20, 2025
@jschwartzentruber
[compiler-rt] Fix frame numbering for unparsable frames. (llvm#148278)
b1306da 
This can happen when JIT code is run, and we can't symbolize those
frames, but they should remain numbered in the stack. An example
spidermonkey trace:

```
    #0 0x564ac90fb80f  (/builds/worker/dist/bin/js+0x240e80f) (BuildId: 5d053c76aad4cfbd08259f8832e7ac78bbeeab58)
    #1 0x564ac9223a64  (/builds/worker/dist/bin/js+0x2536a64) (BuildId: 5d053c76aad4cfbd08259f8832e7ac78bbeeab58)
    llvm#2 0x564ac922316f  (/builds/worker/dist/bin/js+0x253616f) (BuildId: 5d053c76aad4cfbd08259f8832e7ac78bbeeab58)
    llvm#3 0x564ac9eac032  (/builds/worker/dist/bin/js+0x31bf032) (BuildId: 5d053c76aad4cfbd08259f8832e7ac78bbeeab58)
    llvm#4 0x0dec477ca22e  (<unknown module>)
```

Without this change, the following symbolization is output:

```
    #0 0x55a6d72f980f in MOZ_CrashSequence /builds/worker/workspace/obj-build/dist/include/mozilla/Assertions.h:248:3
    #1 0x55a6d72f980f in Crash(JSContext*, unsigned int, JS::Value*) /builds/worker/checkouts/gecko/js/src/shell/js.cpp:4223:5
    llvm#2 0x55a6d7421a64 in CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:501:13
    llvm#3 0x55a6d742116f in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:597:12
    llvm#4 0x55a6d80aa032 in js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICFallbackStub*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) /builds/worker/checkouts/gecko/js/src/jit/BaselineIC.cpp:1705:10
    llvm#4 0x2c803bd8f22e  (<unknown module>)
```

The last frame has a duplicate number. With this change the numbering is
correct:

```
    #0 0x5620c58ec80f in MOZ_CrashSequence /builds/worker/workspace/obj-build/dist/include/mozilla/Assertions.h:248:3
    #1 0x5620c58ec80f in Crash(JSContext*, unsigned int, JS::Value*) /builds/worker/checkouts/gecko/js/src/shell/js.cpp:4223:5
    llvm#2 0x5620c5a14a64 in CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:501:13
    llvm#3 0x5620c5a1416f in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:597:12
    llvm#4 0x5620c669d032 in js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICFallbackStub*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) /builds/worker/checkouts/gecko/js/src/jit/BaselineIC.cpp:1705:10
    llvm#5 0x349f24c7022e  (<unknown module>)
```
OCHyams and others added 14 commits October 22, 2025 14:36
@OCHyams
[AgressiveInstCombine] Merge debug info on merged stores (llvm#164449)
411be14 
A bit of debug info maintenaince for llvm#147540.
@LU-JOHN @arsenm
[AMDGPU] Reland "Remove redundant s_cmp_lg_* sX, 0" (llvm#164201)
9abbec6 
Reland PR llvm#162352. Fix by
excluding SI_PC_ADD_REL_OFFSET from instructions that set SCC = DST!=0.
Passes check-libc-amdgcn-amd-amdhsa now.

Distribution of instructions that allowed a redundant S_CMP to be
deleted in check-libc-amdgcn-amd-amdhsa test:

```
S_AND_B32      485
S_AND_B64      47
S_ANDN2_B32    42
S_ANDN2_B64    277492
S_CSELECT_B64  17631
S_LSHL_B32     6
S_OR_B64       11
```

---------

Signed-off-by: John Lu <[email protected]>
Co-authored-by: Matt Arsenault <[email protected]>
@vtjnash
[MemoryMapper] use thread-local variant for thread-local tests
b00c91a 
Clarify this code does not have access to a TaskDispatcher, and thus is
not permitted use of threads, by using a more efficient single-threaded
monostate variant, instead of making it appear that this test could
potentially be a cause of thread-safety concerns (notably deadlock).
@vtjnash
use TaskDispatch-safe concurrency primitives
05052ba
@vtjnash
some cleanup, race condition fix
145ce28
@vtjnash
DRY with enable_if
1ba10c4
@vtjnash
clang-format
629e3e2
@vtjnash
remove dispatchOutstandingMUs and other cleanups to scheduling
39e0692
@vtjnash
more design enhancements, docs
80d4f4d
@vtjnash
update tests: use getDispatcher().shutdown() between async tests to a…
049b342 
…void needing to update fully to orc::promise
@vtjnash
more test updates (deadlocks) and adapt some blocking function to be …
a3503d6 
…more explicit
@vtjnash
Change design more ergonomic, add future.then()
d0d4c87
@vtjnash
[OrcJIT] distinguish normal and abrupt TaskDispatcher shutdown
8b24fd6 
Add a `run_to_complete` complement to `shutdown`, which does nearly the
same operations, but does not cancel future / pending work. The
distinction is often mainly academic, but split for clarity of intent of
each caller.

Annotate each and every tests that assumes that any previously scheduled
tasks have finished running with a call of `run_to_completion` before
reading the variables written by those tasks. This more clearly
emphasizes the expectations of each of these tests and makes them robust
against data-races or changes to the default scheduler.

These should have no impact currently, but have been tested and shown to
pass with a scheduler which defers all work (as if being run on a
thread) until an explicit synchronization point "acquires" that state,
demonstrating that this is each and every test that would be affected by
changes to the default scheduler.
@vtjnash
rebase errors
b58c15a
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@vtjnash @OCHyams @LU-JOHN