[llvm] [orc::MemoryMapper] use thread-local variant for thread-local operations (PR #154355)

[Lang Hames via llvm-commits]

https://github.com/lhames commented:

Hi @vtjnash. Sorry for the delayed review!

Rather than this change, I think we should revert my patch 3b5842c9c41a441280100045ef62bb8a0fe7200f that introduced the async versions of runAllocActions and runDeallocActions: it was a failed experiment. I apologize for not getting around to removing it earlier.

Background: Deallocation actions are allowed to reside in JIT'd memory, but this makes asynchronous deallocation actions unsafe. E.g. frame-info-registration/deregistration is loaded as part of the JIT runtime (so resides in JIT'd memory), and most object files will contain a deallocation sequence like `[..., deregister-frame-info, ..., deallocate-memory ]`. If deregister-frame-info is asynchronous and tail-call-elimination doesn't kick in (which it won't if we actually make use of the asynchrony) then you end up with a call-stack that looks like:
```
#0 deallocate-memory
...
#N deregister-frame-info
...
```
For the JIT runtime object that introduces the `deregister-frame-info` action, this will lead to us unwinding through the `deregister-frame-info` action that was just deallocated. (This was observed in practice on an experimental branch).

Asynchronous deallocation actions are also incompatible with a future planned "detach" operation that would allow JIT'd code to keep running after the controller disconnects.

Between those two things it seems better for now to require allocation and deallocation actions to be self-contained, synchronous operations.

https://github.com/llvm/llvm-project/pull/154355