This is an archive of the discontinued LLVM Phabricator instance.

[Orc] Use extensible RTTI for the orc::ObjectLayer class hierarchy
ClosedPublic

Authored by sgraenitz on Feb 23 2021, 2:45 PM.

Details

Summary

So far we had no way to distinguish between JITLink and RuntimeDyld in lli. Instead, we used implicit knowledge that RuntimeDyld would be used for linking ELF. In order to get D97337 to work with lli though, we have to move on and allow JITLink for ELF. This patch uses extensible RTTI to allow external clients to add their own layers without touching the LLVM sources.

Diff Detail

Event Timeline

sgraenitz created this revision.Feb 23 2021, 2:45 PM
sgraenitz requested review of this revision.Feb 23 2021, 2:45 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 23 2021, 2:45 PM
sgraenitz edited the summary of this revision. (Show Details)Feb 23 2021, 2:45 PM
lhames requested changes to this revision.Feb 23 2021, 2:48 PM

We should use ExtensibleRTTI.h for this. Performance is a non-issue here, and I would like clients to be able to supply their own reference linking layers (e.g. one that just calls out to ld then dlopens).

This revision now requires changes to proceed.Feb 23 2021, 2:48 PM
sgraenitz added a comment.EditedFeb 25 2021, 9:18 AM

Thanks for having a look. Yes, extensibility is a good point. I switched it to the ExtensibleRTTI implementation and it works well. It's the first use-case in LLVM so far: https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html#rtti-for-open-class-hierarchies

I have to admit I am not very happy with the CRTP approach in there. I hacked forward a bit to look for an alternative and it is possible: https://reviews.llvm.org/differential/diff/326409/#change-EaiHppkLE6Ki, but it's not in a state where it could land any time soon and I don't have the capacity to get it ready for review now.

sgraenitz updated this revision to Diff 326423.Feb 25 2021, 9:18 AM

Switch to extensible RTTI

sgraenitz retitled this revision from [Orc] Add LLVM-style RTTI for orc::ObjectLayer to [Orc] Use extensible RTTI for the orc::ObjectLayer class hierarchy.Feb 25 2021, 9:25 AM
sgraenitz edited the summary of this revision. (Show Details)

Thanks for having a look. Yes, extensibility is a good point. I switched it to the ExtensibleRTTI implementation and it works well. It's the first use-case in LLVM so far: https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html#rtti-for-open-class-hierarchies

I have to admit I am not very happy with the CRTP approach in there.

Could you describe more what you find off-putting about it?

I hacked forward a bit to look for an alternative and it is possible: https://reviews.llvm.org/differential/diff/326409/#change-EaiHppkLE6Ki, but it's not in a state where it could land any time soon and I don't have the capacity to get it ready for review now.

This alternative, at least, looks like it uses an extra non-static member variable, compared to the original use of a static member. That's a fairly significant tradeoff/cost to add in terms of extra size to every derived object.

lhames accepted this revision.Feb 25 2021, 6:21 PM

This alternative, at least, looks like it uses an extra non-static member variable, compared to the original use of a static member. That's a fairly significant tradeoff/cost to add in terms of extra size to every derived object.

Yeah -- We considered designs using a non-static type member at the time, but decided against them for this reason. I haven't come up with a good solution that avoids CRTP and static members yet.

This revision is now accepted and ready to land.Feb 25 2021, 6:21 PM

Could you describe more what you find off-putting about it?

First of all I think the current implementation is reasonable and pragmatic. CRTP adds artificial layers to the class hierarchy, which can be a pain for the reader and the debugger. Maybe it's personal preference, years ago I worked on a project that used CRTP heavily and it was a pain (pre C++14 inheriting ctors).

This alternative, at least, looks like it uses an extra non-static member variable, compared to the original use of a static member. That's a fairly significant tradeoff/cost to add in terms of extra size to every derived object.

Well, I considered the idea promising. For each instance overhead is "length of inheritance chain" times "1 direct call for construction and 1 byte memory (plus alignment)" plus "one pointer in the root". Bad for small payloads and inner loops of course, but ORC ObjectLayers... Would be great, if it was possible with only the one extra member, but I didn't get rid of the extra using and that makes it odd. Another major concern is compile time overhead and additional archive size, as the whole template machinery gets pulled into Casting.h too. So, I guess there is not much coming out of my hack for now. Maybe on a lazy Sunday I get back to it :)