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?
In fact, this is all very good practice in my opinion:
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! @Machiel: This is quite recent, but didn’t land after it was accepted. Objections? Cheers
I can also confirm that this other bug that I reported a while ago is still relevant with ORCv2: https://bugs.llvm.org/show_bug.cgi?id=40074
It is a rather impactful one on COFF/Windows. There is an effective workaround though.
The COFF side of ORC still needs a few other workarounds to be enabled for it to work properly. It could use some more developer attention.
One off them I believe is a workaround for https://bugs.llvm.org/show_bug.cgi?id=25493, so that one is still relevant as well.
I might contribute some more patches in that direction in the future if I can find the time, though I have limited experience with llvm.
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, llvm.org/PR41595
In my experience the Windows incompatibilities are hard to tackle. I am not surprised having a number of permanent tickets there.
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.
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.
