[LLVMdev] Finding safe thread suspension points while JIT-ing (was: Add pass run listeners to the pass manager.)

[Chandler Carruth]

So, I'm bringing a discussion that has thus far been on llvm-commits to
llvmdev because I finally (and thanks for helping me understand this Andy)
understand what is *really* going on, and I think lots of others need to be
aware of this and involved to figure out the right path forward.

You can find the full review thread and more context under the subject
"[PATCH][PM] Add pass run listeners to the pass manager.", but here is the
important bit from Juergen's initial email:

this patch provides the necessary C/C++ APIs and infastructure to enable
> fine-
> grain progress report and safe suspension points after each pass in the
> pass
> manager.



Clients can provide a callback function to the pass manager to call after
> each
> pass. This can be used in a variety of ways (progress report, dumping of
> IR
> between passes, safe suspension of threads, etc).


I had wrongly (perhaps because of the implementation, but still, wrongly)
focused on the progress report and IR dumping use cases. It sounds (from
talking to Andy offline, sorry for that confusion) like the real use case
is safe suspension of threads. The idea is that we would have a callback
from the pass manager into the LLVMContext which would be used to recognize
safe points at which the entire LLVMContext could be suspended, and to
expose these callbacks through C API to JIT users.

Increasingly, I can't fathom a way to get a good design for safe suspension
of JIT-ing threads using callbacks tied to when passes run today. I think
it is a huge mistake to bake this into the C API at this point. If you need
this functionality in the C API, with a design we can use going forward,
I'd like to see a *really* careful write up of exactly what the suspension
point requirements are and a design for achieving them. I think it should
be completely independent from any infrastructure for reporting or dumping
IR in pass managers.

I think something much simpler than this might work outside of the C API,
where we can essentially change how it works when we start designing how
multiple threads will actually work within an LLVMContext. Would that work?
Is there a way to make progress more rapidly there?

Ultimately, this is opening a huge can of worms if we put it into the C
API, as I think it is going to fundamentally impact what options we
actually have for parallelizing parts of LLVM in the future. If we want to
go there, we need be *incredibly* explicit about what assumptions are being
made here.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140509/60da1f0c/attachment.html>