[PATCH] D39111: Extensible LLVM RTTI

[Lang Hames via Phabricator via llvm-commits]

lhames added a comment.

In D39111#1928251 <https://reviews.llvm.org/D39111#1928251>, @dblaikie wrote:

> In D39111#1925642 <https://reviews.llvm.org/D39111#1925642>, @lhames wrote:
>
> > @dblaikie, @chandlerc -- Any further thoughts on this one?
>
>
> I'd like Chandler to come back around on this, given the reservations he expressed, but not sure he'll get to it - so might have to just figure it out ourselves. I share some of those reservations (that'd be easy to misuse this & have code that doesn't work on Windows - people won't read the documentation & might write the broken template situation), but maybe less concerned than Chandler was.


Were there reservations about windows related to this patch? This certainly came up with the original design of the RTTI for Error: ErrorInfo originally defined the ID member for you, which Chandler pointed out is unsafe on Windows. We solved that in the ErrorInfo case by requiring you to define the ID member in your own class, and RTTIExtends takes the same approach.

>> I'd like to get this in as we have some use cases in the JIT (e.g. querying and down casting to user defined MaterializationUnit types when dispatching JIT work). At the time these were future use cases, now they're current ones. :)
> 
> Could you sketch up a user/use case to demonstrate the use (maybe a Kaleidoscope example?)?

Here are some simplified versions of the two use cases I want to use straight away:

In LLJIT set up we want the object linking layer type to be detectable to simplify setup code. E.g.

  auto J = ExitOnErr(LLJITBuilder().create());
  if (auto *RTDyldLinkLayer = dyn_cast<RTDyldObjectLinkingLayer>(J->getObjLinkingLayer()))
    RTDyldLinkLayer->setProcessAllSections(...);
  else if (auto *ObjLinkLayer = dyn_cast<ObjectLinkingLayer>(J->getObjLinkingLayer()))
    installObjLinkingLayerPlugins(*ObjLinkingLayer);

In the dispatcher we want to be able to inspect the dynamic type of MU to decide how to dispatch the work:

  ES.setDispatchMaterialization([](JITDylib &JD, std::unique_ptr<MaterializationUnit> MU) {
    if (isa<SplattingMaterializationUnit>(*MU))
      MU->doMaterialize(JD); // Materialize splatting MUs in-place.
    else if (auto &IRMU = dyn_cast<IRMaterializationUnit>(*MU))
      dispatchIRMU(std::move(MU)); // Analyze IR and decide how to dispatch
    else
      CompileThreads->async([MU=std::move(MU), &JD]() {
        MU->doMaterialization(JD); // Otherwise default to materializing on background thread
      });
  });

As soon as this lands I'll add an OrcV2Example project covering it. Stefan is also planning to use this in his ThinLtoJIT example.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D39111/new/

https://reviews.llvm.org/D39111