Rename LLJIT and OrcEE header doxygen groups

Rename LLJIT and OrcEE header doxygen groups

Hi, are these test cases supposed to be under /llvm in the monorepo? Right now they are at a new path, /llvm/clang/test/... which doesn't look right.

In D103267#2906602, @lhames wrote:

Hi Mats. Looks like this was superseded by https://reviews.llvm.org/D106764. Is that right? If so we can close this.

Ping

I do not have commit access, so it would be appreciated if somebody could land this for me.

I do not have commit access so it'd be great if somebody could land this on my behalf.

In D102710#2767524, @ikudrin wrote:

GTEST_SKIP() may be called in OrcCAPITestBase::SetUp() so that checks can be removed in every separate test.

[NFC][test] replace if clauses in all tests with GTEST_SKIP() in SetUp

It looks like my local branch was a bit behind tip of tree when I started working on it which meant that https://reviews.llvm.org/rG34a8a437bf20e0a340c19ed1fdb9cca584d43da1 wasn't checked into my local branch.

[NewPM] Remove documentation comments for parameters that were refactored into LLVMPassBuilderOptionsRef

Found a tiny mistake in one of the comments, will fix.

In D102136#2760416, @aeubanks wrote:

looks good aside from one super duper nit
do you have commit permission?

[NewPM] Re-arrange order of arguments for LLVMRunPasses

[NewPM] Abstract PipelineTuningOptions away into LLVMPassBuilderOptions

In D102136#2757551, @aeubanks wrote:

looks pretty good, just one nit

[NewPM] Extract LLVMRunPasses options into LLVMPassBuilderOptionsRef

Okay so I had some troubles with arc, but I think I finally got it right. I've now refactored LLVMRunPassBuilder into LLVMRunPasses with the changes we went through earlier and I've added the StandardInstrumentations inside of that function.

[NewPM][C-bindings] Keep PassBuilder private to LLVMRunPasses and enable StandardInstrumentation

[NewPM][C-bindings] Keep PassBuilder private to LLVMRunPasses and enable StandardInstrumentation

[NewPM][C-bindings] Keep PassBuilder private to LLVMRunPasses and enable StandardInstrumentations

In D102136#2749370, @aeubanks wrote:

In D102136#2749071, @supergrecko wrote:

In D102136#2748572, @aeubanks wrote:

The weird quirk of disposing the PassBuilder when it's passed to LLVMRunPassBuilder and the awkward naming of LLVMRunPassBuilder are easily resolved if we combine the two, since PassBuilder will be internal to that one function, and LLVMRunPasses seems nice

LLVMRunPasses would be nice and descriptive for its task. I'm not too sure I understood what you mean by "the quirk of disposing the PassBuilder (...)"; would it be preferable to have the client dispose it themselves? If the PassBuilder is re-usable after a run it would probably not make sense to get rid of it, but you know more about that than I do. Let me know what you think is the correct decision here.

It's weird that clients only sometimes manually dispose of the PassBuilder. For example, if a language with destructors were to wrap LLVMPassBuilderRef, there'd be weird logic in the destructor on when to call LLVMDisposePassBuilder. I'm not worried about supporting reusing a PassBuilder.
IMO we should only have the creation/setup of options (in this case PTO, maybe some other things like DebugLogging and TargetMachine), then pass those options and the pass pipeline string and the module to a LLVMRunPasses. This simplifies everything and we don't have to worry about any LLVMPassBuilderRefs since we won't be exposing it.

In D102136#2748572, @aeubanks wrote:

The weird quirk of disposing the PassBuilder when it's passed to LLVMRunPassBuilder and the awkward naming of LLVMRunPassBuilder are easily resolved if we combine the two, since PassBuilder will be internal to that one function, and LLVMRunPasses seems nice

I think you can build PassBuilder with an uninitialized PassInstrumentationCallbacks object and retrieve it via PassBuilder::getPassInstrumentationCallbacks before populating it with StandardInstrumentation when FunctionAnalysisManager is available (getPassInstrumentationCallbacks is marked const but the returned pointer is not so I'm not complaining :-P. Plus, the comment for getPassInstrumentationCallbacks also hints this usage).

That sounds like the solution I was looking for. Excellent, thank you!

Not quite sure how we want to register the StandardInstrumentations here... Right now it's not registering any PassInstrumentationCallbacks at all because I'm not too sure how we wanted to handle that either.

This was an accidental push to LLVM reviews and it should be ignored as this is patch was already merged into upstream by a different contributor.

I'm completely new to arcanist and everything and it seems I've used the wrong commands here. This is the latest commit to main and is none of my work. Is there a way to undo this?