This is an archive of the discontinued LLVM Phabricator instance.

[WIP] LLJITTest
AbandonedPublic

Authored by sgraenitz on Aug 21 2018, 10:45 AM.

Details

Reviewers
lhames
Summary

Getting familiar with the new API

Diff Detail

Event Timeline

sgraenitz created this revision.Aug 21 2018, 10:45 AM
sgraenitz updated this revision to Diff 161950.Aug 22 2018, 7:20 AM

Split up into 4 usage examples. This goes from a very simple use case to more advanced ones.

It illustrates 2 current issues:

  • PassManager::run() seems to be not thread-safe, thus the extra mutex in IRCompileLayer2::emit().
  • JITing from different threads causes deadlock during symbol lookup.
sgraenitz updated this revision to Diff 161977.Aug 22 2018, 9:04 AM

Add more polishing, explanations, fixmes

Maybe it makes sense in oder to illustrate the usage of your API, to give people a very simple example (like UnthreadedSingleDylib) and extended it step by step to more advanced ones (like ThreadedMultiDylib).

I don't see how to avoid the PassManagerRunMutex in IRCompileLayer2::emit():

  • I tried to add mutexes in MCAssembler, TargetLoweringObjectFile, AtomicExpandPass, etc., but it got very complicated very quickly. Everything goes through PassManager::run(), but a mutex there would affect a lot of other code. IRCompileLayer2 appeared to be a good point.
  • I always thought that support for multithreaded codegen is implicitly given when using different LLVMContext instances. It doesn't look like that here. Maybe there's more requirements to it?
unittests/ExecutionEngine/Orc/LLJITTest.cpp
55

Changed example functions: foo and bar are disjunct now, buz is the one that depends on both of them.

161

The thread that runs DispatchMaterialization can't be blocked, right? So it must spawn a new thread, which must be joined back to this thread later. How do we know the correct one? Track it in MaterializationUnit and join in destructor? Also see my below comments.

184

Can't join the DispatchMaterialization thread here, because I don't know whether it's M[0] or M[1].

190

Concurrent lookup for foo and bar works due to the mutex in IRCompileLayer2::emit().

194

This randomly causes failures. I think threads should always be joined in the thread that they were forked from. Not simple, even with a fixed-size thread pool.

269

No barrier with JoinAll necessary here. Maybe because foo and bar are in other dylibs?

sgraenitz added inline comments.Aug 22 2018, 9:48 AM
lib/ExecutionEngine/Orc/IRCompileLayer.cpp
26 ↗(On Diff #161950)

PassManagerRunMutex is here. It's not included in the reviews main diff. Not sure why.

sgraenitz added inline comments.Aug 22 2018, 10:52 AM
unittests/ExecutionEngine/Orc/LLJITTest.cpp
161

Track it in MaterializationUnit and join in destructor?

The last shared ref to SMU below is in the newly spawned thread, so this won't work.

sgraenitz abandoned this revision.Aug 22 2018, 1:15 PM

I collected quite some unnecessary noise here. Will close this and open dedicated ones for proposals.