User Details
- User Since
- Feb 27 2013, 2:34 PM (525 w, 4 d)
Today
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.
Fri, Mar 24
Thu, Mar 23
Wed, Mar 22
Relocation names should be generic (at least for getEdgeKindName), but otherwise LGTM!
LGTM. Thanks @sgraenitz!
Mon, Mar 20
Sun, Mar 19
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).
Sat, Mar 18
Fri, Mar 17
Thu, Mar 16
New commit language on edges between Standard/Finalize and NoAlloc sections:
Use NoAlloc lifetime in LinkGraphBuilders for COFF, ELF and MachO.
Wed, Mar 15
LinkGraphBuilder changes TBD.
Tue, Mar 14
Very belatedly landed. Thanks again for this Frank!
This was reapplied with fixes in 0283b07746e87.
LGTM. Thanks @tstellar!
Sat, Mar 11
Thu, Mar 9
Hi Aman,
Sun, Mar 5
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.
Wed, Mar 1
Feb 22 2023
Feb 21 2023
Feb 20 2023
Yep -- just moves the lambda body out into a method. NFC.
Feb 17 2023
Feb 15 2023
Very cool. Thank you for contributing this -- it's great to finally see ARM32 support in JITLink! :)
Feb 14 2023
Feb 13 2023
Feb 12 2023
Feb 11 2023
Feb 10 2023
Feb 8 2023
LGTM.
Feb 4 2023
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.
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.
Feb 3 2023
Feb 1 2023
Jan 31 2023
Address latest feedback.
LGTM. Thanks @wangleiat!
Jan 30 2023
Are there any further comments on this patch? If not I'll go ahead and land it based on Pete's approval.
Jan 29 2023
Looks great! Thanks very much @jain98!
Jan 28 2023
Jan 24 2023
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.
LGTM!
Jan 23 2023
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.