[llvm-dev] OrcV1 removal

[Andres Freund via llvm-dev]

Hi,

On 2020-09-16 11:52:11 -0700, Lang Hames wrote:
> I've updated the orcv1 removal branch (
> https://github.com/lhames/llvm-project/tree/orcv1-removal) with an initial
> patch for removable code. If anyone wants to follow along with the
> development or share thoughts on the design you're very welcome to.

Cool!I assume this works on "non-native" jitlink platforms as well? Or
just mach?

Looks like there's not yet a C API yet - not a problem, just checking.

Currently it looks like only the main jit dylib is exposed via C, right?
We can't really do the same for resource trackers, if I understand this
correctly. Sketching out what I'd need to do to test postgres, so I
don't waste time going in the wrong direction:

1) Add API for management (create, destroy) a non-default resource tracker
   (i.e. JITDylib::createResourceTracker)
3) Add JITDylib::clear() wrapper
2) LLVMOrcLLJITAdd{LLVMIRModule,ObjectFile} would need a new argument
   (defaulting to NULL for the default resource tracker?) to specify the
   resource tracker
4) LLJIT would need to grow the underlying support methods

Does that sound roughly right?

Independent questions about the current C API:
- Would be nice to document [non-]mangling behaviour of
  LLVMOrcLLJITLookup()
- Do I understand correctly that there's no way to keep a memory buffer
  with an object file alive after adding it with
  LLVMOrcLLJITAddObjectFile()? But that it's fine to create multiple
  buffers for the same memory with LLVMCreateMemoryBufferWithMemoryRange()?


> You can call ResourceTracker::remove at any time to remove all symbols and
> resources associated with a tracker. Any active compiles associated with
> the tracker will receive an error when they try to update the JIT state via
> their MaterializationResponsibility, and will not be able to associate
> resources with the tracker's associated ResourceKey.
>
> You can call ResourceTracker::transferTo at any time. This will transfer
> tracking of all associated symbols and resources to the destination
> tracker. Any active compiles associated with the tracker will be
> reassociated with the destination tracker, and all future resources will be
> associated with the destination tracker. Merging trackers can reduce
> administrative overhead, especially when merging onto the default tracker
> for the JITDylib, which has a more compact representation for ownership of
> symbols.
> 
> Calling JITDylib::clear() will call remove on all trackers created by the
> JITDylib (including the default one).
> 
> ResourceTrackers have shared ownership, but the ExecutionSession and
> JITDylib do not retain ownership (except for the default tracker). If you
> release all pointers to a tracker its resources will be automatically
> transferred (via transferTo) to the default tracker for the JITDylib.

I assume it is not legal to use the same resource tracker with two
different JITDylib's?


Greetings,

Andres Freund