I already has a patch for this, but it is still in review because of unrelated stuff to this issue. So please go head and commit this.

The change set is committed in rL367756.

Adapt to new locking scheme

Resolve comments

1. Included a Example to show how to use speculation,

I reverse the list as 2.7 3.5 3.6 3.7 it fixes the issue, but I don't know whether it is correct or not.

Hey guys, I get cmake error at configuration time " Found incompatible python interpreter version and python libraries version". I have both python 2.7 and python 3.6, cmake now finds python interpreter version 3.6 and python libs 2.7, hence the incompatibility. How I can rectify this?

In D63378#1576628, @pree-jackie wrote:

lhames idea :

Remove Speculator variants for different program representations and handle them via ORC Layers.

lhames idea :

In D63378#1575917, @pree-jackie wrote:

In D63378#1575196, @lhames wrote:

Hi Praveen,

I'm not sure the IRSpeculator is necessary. My instinct would be to just have the Speculator class as the global repository of estimates of the form "execution point -> { candidates to speculatively compile }" (i.e. your GlobalSpecMap). Then the IRSpeculationLayer should take a reference to the Speculator and use a custom FunctionPass to populates the estimates.

I've attached an example of a hand rolled pass pipeline that should give you access to statically calculated block frequency estimates:

block-freq-pass-example.cpp2 KBDownload

• Lang.

I think it is really a matter of separation, that is where we analysis the module and retrieve the results that means whether in a layer or a speculator object, If we take over the layer approach we have to make the Pass to be aware of speculator.

In D63378#1575196, @lhames wrote:

Hi Praveen,

I'm not sure the IRSpeculator is necessary. My instinct would be to just have the Speculator class as the global repository of estimates of the form "execution point -> { candidates to speculatively compile }" (i.e. your GlobalSpecMap). Then the IRSpeculationLayer should take a reference to the Speculator and use a custom FunctionPass to populates the estimates.

I've attached an example of a hand rolled pass pipeline that should give you access to statically calculated block frequency estimates:

block-freq-pass-example.cpp2 KBDownload

• Lang.

In D63378#1574241, @hfinkel wrote:

Can you please upload a patch with full context?

Ping :)

Additions in this Change Set

Added __orc_speculate_for , and orc_speculator. Remaining are test-cases, once test case is added I think it is ready to go, without major changes

Fixed comments,

I think it's more of an race condition than a data race. I will write a test case and check whether TSan can catch it. But the idea here is createJITDylib and getJITdylibByName must be executed by the same thread,

Hi Lang, thank you for the comments.
I'm reading those and I'll address those shortly.

Always Welcome

ping,
Whether docs is okay?

Added user documentation part 2, It is ready to go now.

User Documentation - Part 1

Adding IRTransformLayer to Optimize IR *Modules* Lazily

toy.cpp is already updated for chapter 1&2.

Thanks :)
Then we can change parameter type of createJITDylib to StringRef instead of std::string.

Updated Diff file

Whether two diff set like this can be merged? How I can update these individual diff's to view all changes in a single diff?

Wrapping the getJITDylibByName by runSessionLocked Interface to make thread safe creation of JITDylibs

Thank you!