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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
2,020 ms | x64 debian > libarcher.races::lock-unrelated.c |
Event Timeline
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).
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.
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.
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.
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 :)