[llvm-dev] Bugzilla OrcJIT Tickets

Mon Aug 5 11:55:56 PDT 2019

> An interesting follow up question would be what form people would like
> to see the ORCv2 C APIs take.
>
> The minimalist path would be to just expose LLJIT/LLazyJIT’s
> functionality via a C API.
>
> The maximalist path would be to expose the raw ORCv2 interfaces
> (things like MaterializationUnit, ObjectLayer, IRLayer, etc.) so that
> C API users can potentially inject their own layer/mat-unit
> implementations into stacks along with existing layers. 
>
> I would lean towards the former. If we could pin down a nice
> remote-process model for LLJIT/LLLazyJIT the resulting C interface
> could give us the feature-set promised by ExecutionEngine’s interface
> (a feature-set that no actual implementation has ever provided), plus
> concurrency.
Good point. I'd like to see the C bindings as "LTS" version of the LLVM
API. Indeed ORCv2 got more and more stable, but I wouldn't say it
reached the point, where its details should be nailed down to an API
that aims for long-term support. It would likely either break or
complicate upcoming changes. The former is more likely to remain stable
over the next couple of releases, so I'd vote for it too.

Maybe the decision made, should be revisited from time to time.

On 12/07/2019 03:07, Lang Hames wrote:
> Hi Stefan,
>
>> Maybe this is worth a discussion, as I have seen people confused (and
>> I am not up-to-date either):
>> * Are the C-bindings meant to be functional for OrcV1 and OrcV2?
>> * Do they provide full or partial functionality? 
>> * Which parts work, which don't?
>>
> Good questions!
>
> The C-bindings are backed by ORCv1. I expect them to change, if not
> receive a full re-write, when ORCv1 is deprecated.
>
> The C APIs for ORCv1 could only ever provide partial functionality,
> given how pervasive template usage was in ORCv1.
>
> The parts that are used by the ORCCBindings unit test definitely work.
> For everything else... your mileage may vary.
>
> An interesting follow up question would be what form people would like
> to see the ORCv2 C APIs take.
>
> The minimalist path would be to just expose LLJIT/LLazyJIT’s
> functionality via a C API.
>
> The maximalist path would be to expose the raw ORCv2 interfaces
> (things like MaterializationUnit, ObjectLayer, IRLayer, etc.) so that
> C API users can potentially inject their own layer/mat-unit
> implementations into stacks along with existing layers. 
>
> I would lean towards the former. If we could pin down a nice
> remote-process model for LLJIT/LLLazyJIT the resulting C interface
> could give us the feature-set promised by ExecutionEngine’s interface
> (a feature-set that no actual implementation has ever provided), plus
> concurrency.
>
> What do others think?
>
> — Lang.
>
> Sent from my iPad
>
> On May 23, 2019, at 11:42 AM, Stefan Gränitz
> <stefan.graenitz at gmail.com <mailto:stefan.graenitz at gmail.com>> wrote:
>
>> Thanks for your attention! We found 7 outdated issues and reviewed 8
>> more that now describe a way forward.
>> This was a good step towards overview :)
>>
>> The remaining long-standing reports gather around 2 hotspots:
>>
>> Missing functionality and workarounds on Windows: llvm.org/PR25493
>> <http://llvm.org/PR25493>, llvm.org/PR41595 <http://llvm.org/PR41595>
>> In my experience the Windows incompatibilities are hard to tackle. I
>> am not surprised having a number of permanent tickets there.
>>
>> C-API bindings: llvm.org/PR31101 <http://llvm.org/PR31101>,
>> llvm.org/PR31103 <http://llvm.org/PR31103>, llvm.org/PR32628
>> <http://llvm.org/PR32628>, llvm.org/PR36896 <http://llvm.org/PR36896>
>>
>> Maybe this is worth a discussion, as I have seen people confused (and
>> I am not up-to-date either):
>> * Are the C-bindings meant to be functional for OrcV1 and OrcV2?
>> * Do they provide full or partial functionality?
>> * Which parts work, which don't?
>>
>> Best
>> Stefan
>>
>> On 5/18/19 8:02 PM, Praveen Velliengiri wrote:
>>> Hi Stefan
>>> Thank you!
>>> In case, you missed in llvm-dev listing: you can find the proposal
>>> here : link.
>>> <https://docs.google.com/document/d/1202EcXlWMQ8yxu5qD0b5fE0a_kihlcaPNpZo_Jk0YeQ/edit?usp=sharing>
>>> Thanks for working on summarising the Bugzilla tickets to track the
>>> recent changes in ORC this is really helpful.
>>>
>>>
>>> On Sat, 18 May 2019 at 21:33, Stefan Gränitz
>>> <stefan.graenitz at gmail.com <mailto:stefan.graenitz at gmail.com>> wrote:
>>>
>>>     In fact, this is all very good practice in my opinion:
>>>     https://bugs.llvm.org/show_bug.cgi?id=30896
>>>     https://bugs.llvm.org/show_bug.cgi?id=22608
>>>     https://bugs.llvm.org/show_bug.cgi?id=24159
>>>
>>>     Back in 2016 I simply didn't know about the Bugzilla tracker.
>>>     From today's perspective, I think, we should try and revive this
>>>     spirit and share rough plans there.
>>>
>>>     @Praveen very good initiative!
>>>     https://bugs.llvm.org/show_bug.cgi?id=41075
>>>
>>>     @Machiel: This is quite recent, but didn't land after it was
>>>     accepted. Objections?
>>>     https://reviews.llvm.org/D61599
>>>
>>>     Cheers
>>>
>>>     -------- Forwarded Message --------
>>>     Subject: 	Bugzilla OrcJIT Tickets
>>>     Date: 	Sat, 18 May 2019 17:47:58 +0200
>>>     From: 	Stefan Gränitz <stefan.graenitz at gmail.com>
>>>     <mailto:stefan.graenitz at gmail.com>
>>>     To: 	via llvm-dev <llvm-dev at lists.llvm.org>
>>>     <mailto:llvm-dev at lists.llvm.org>
>>>
>>>
>>>
>>>     Hello everyone
>>>
>>>     A previous thread about OrcJIT brought up bug reports on Bugzilla. A
>>>     quick search gives 20+ results:
>>>     https://bugs.llvm.org/buglist.cgi?component=OrcJIT&list_id=162232&query_format=advanced&resolution=---
>>>
>>>     While some of them are obviously outdated (addModuleSet API cleanup
>>>     [1]), others may actually be relevant again (Small code model?
>>>     [2]). If
>>>     you reported one of them, please take the time (some day) and review
>>>     from today's perspective.
>>>
>>>     Are there recommendations regarding Bugzilla reports from other
>>>     parts of
>>>     LLVM? Best practices that worked out well?
>>>
>>>     Thanks!
>>>     Stefan
>>>
>>>     --
>>>
>>>     [1] https://bugs.llvm.org/show_bug.cgi?id=30896
>>>     [2] https://bugs.llvm.org/show_bug.cgi?id=24159
>>>
>>>     -- 
>>>     https://flowcrypt.com/pub/stefan.graenitz@gmail.com
>>>
>>>
>>>
>> -- 
>> https://flowcrypt.com/pub/stefan.graenitz@gmail.com

-- 
https://flowcrypt.com/pub/stefan.graenitz@gmail.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190805/e916f402/attachment-0001.html>