Is there something preventing Bolt from moving to ORC / JITLink? If Bolt is able to move over then the aim should be to do that. If Bolt is unable to move over then we need to know why so that we can address the issue. RuntimeDyld is very much in maintenance mode at the moment, and we're working hard to reach parity in backend coverage so that we can officially deprecate it.

Relocation names should be generic (at least for getEdgeKindName), but otherwise LGTM!

LGTM. Thanks @sgraenitz!

In D146391#4205531, @pchintalapudi wrote:

For testing, there are a couple of options that I think should be possible.

Right now D146169's test is only that the jitdump file exists, not on the accuracy of the content. I've been verifying the content of that file using my own custom python script, so one option is to upload that script (to where?), output to json, and check that json for accuracy (with what tools?).

In D146169#4205438, @pchintalapudi wrote:

Do the perf JIT APIs support unloading code? If so these should have a // TODO to fill them in later. (I don't think they're needed for the initial commit).

I don't see any records for code unloading in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/Documentation/jitdump-specification.txt , and PerfJITEventListener didn't have support for code unloading either, so I'm inclined to believe it doesn't exist right now.

Thanks very much @pchintalapudi!

This looks great -- thanks very much @pchintalapudi!

For the Linux failure it looks like test/ExecutionEngine/OrcLazy/emulated-tls.ll just needed -lljit-platform=Inactive added to preserve the existing failure mode. I'll add that when I update the review this evening.

Accidentally landed this before it was ready -- my apologies.

@Panzerschrek I don't have a problem with this landing, but want to echo Hahnfeld's point: the interpreter is legacy mode at this point. While there are no immediate plan to remove it, it's not being actively maintained either, and it's possible that it will be removed in a future version (though I would expect us to give a deprecation warning well in advance).

New commit language on edges between Standard/Finalize and NoAlloc sections:

Use NoAlloc lifetime in LinkGraphBuilders for COFF, ELF and MachO.

LinkGraphBuilder changes TBD.

Very belatedly landed. Thanks again for this Frank!

This was reapplied with fixes in 0283b07746e87.

LGTM. Thanks @tstellar!

Hi Aman,

My gut reaction is to want to introduce a new "target flags" concept into Symbol, rather than using/abusing the address. On the other hand I think that using/abusing the address is the standard for thumb, and people might get thrown if this bit _isn't_ where they expect it to be.

Yep -- just moves the lambda body out into a method. NFC.

Very cool. Thank you for contributing this -- it's great to finally see ARM32 support in JITLink! :)

LGTM.

In D142443#4104430, @Hahnfeld wrote:

I received three complaints from AArch64 bots now failing Clang Interpreter tests, for example: https://lab.llvm.org/buildbot/#/builders/197/builds/3920 I don't quite understand how this can happen and currently have no easy way to verify, so reverting a second time...

LLJIT has been update to default to JITLink on arm64 in 6747fc07d1aa, and on my local machine the interpreter tests now pass with this patch applied.

In D143039#4104425, @MaskRay wrote:

In D143039#4104375, @lhames wrote:

My best guess is that the JIT linker is dropping this. I'm just doing a Linux build now so that I can figure out what's going wrong.

I suspect that 43acef48d38ec0dd391f212144d4a25095e4fc5f has incomplete support.

JIT session error: Symbols not found: [ DW.ref.__gxx_personality_v0 ]

If I hand-compile source for the failing simple-execution.cpp testcase on Darwin with clang --target=arm64-pc-linux-gnu -fno-pic -S I see new references to DW.ref.__gxx_personality_v0, but I also see a definition:

        .hidden DW.ref.__gxx_personality_v0
        .weak   DW.ref.__gxx_personality_v0
        .section        .data.DW.ref.__gxx_personality_v0,"aGw",@progbits,DW.ref.__gxx_personality_v0,comdat
        .p2align        3, 0x0
        .type   DW.ref.__gxx_personality_v0,@object
        .size   DW.ref.__gxx_personality_v0, 8
DW.ref.__gxx_personality_v0:
        .xword  __gxx_personality_v0

My best guess is that the JIT linker is dropping this. I'm just doing a Linux build now so that I can figure out what's going wrong.

In D142443#4103013, @thakis wrote:

Instead of adding an xfail, does it make more sense to pass an explicit triple to lli instead?

Address latest feedback.

LGTM. Thanks @wangleiat!

Are there any further comments on this patch? If not I'll go ahead and land it based on Pete's approval.

Looks great! Thanks very much @jain98!

This looks right to me -- the verifier already requires available_externally aliases to point to other available_externally symbols, so if we're skipping an alias here then we know that we'll also skip all the things that it points to.

Address review feedback.

In D142188#4076374, @Hahnfeld wrote:

Sure, but is this actually relevant? Passing foo is not properly mangled and an error on the client side.

LGTM!

Here's a potential testcase, for anyone who wants to try this out. You'll need to build LLVM, compiler-rt, and libunwind:

JITTargetMachineBuilders are only moved around at startup at the moment, and they're only ~0.5kb. Have they been observed to have a performance impact? If so we should probably transfer them via unique_ptr to avoid the copies, but I'm not sure it's necessary yet.