-
-
Notifications
You must be signed in to change notification settings - Fork 267
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for LLVM 16 and bump LDC-LLVM to v16.0.6 for prebuilt packages #4423
Conversation
Signed-off-by: Ikey Doherty <ikey@serpentos.com>
Signed-off-by: Ikey Doherty <ikey@serpentos.com>
In stable LLVM 16 this is now under `Support` and not `IR` Signed-off-by: Ikey Doherty <ikey@serpentos.com>
The StandardInstrumentations type now takes an LLVMContext parameter so pass it along from the current module. Signed-off-by: Ikey Doherty <ikey@serpentos.com>
Instructions now use friend APIs to add themselves into a BasicBlock, rather than a BasicBlock having an API to add the instructions. Signed-off-by: Ikey Doherty <ikey@serpentos.com>
This was killed upstream in the codegen pipeline as part of a bunch of legacy PM removals: - https://reviews.llvm.org/D137116 Signed-off-by: Ikey Doherty <ikey@serpentos.com>
This isn't *the* most ideal approach and in future we may want to select specific fallbacks other than "generic". Signed-off-by: Ikey Doherty <ikey@serpentos.com>
Unfortunately when building with LLVM < 15, we're using C++-11, so the std::optional bits are only available in C++-17. Even more unfortunately we can't really override this, rather inherit the fact of using C++-17 when using LLVM > 16. Thus, we add a slightly messy conditional compilation situation to allow usage of LDC on older LLVM versions, and with newer LLVM/libcxx. Signed-off-by: Ikey Doherty <ikey@serpentos.com>
Modified to have an explicit `main()` per the other profdata imports in this tree. Signed-off-by: Ikey Doherty <ikey@serpentos.com>
Signed-off-by: Ikey Doherty <ikey@serpentos.com>
Regarding the rather immediate crashes when compiling druntime/Phobos, we'll probably need an LLVM with enabled assertions to check for LLVM 16 changes. |
@thewilsonator: The GitHub Actions |
Thanks, Will take a look over the weekend |
The dmd-testsuite regressions (2 failures with apparently same cause) with that LDC-LLVM 16 on Mac and Windows look really bad:
Smells like a miscompile of the compiler itself. I've checked the garbage strings, they are passed as literals to |
Looking at it, that seems to be harmless. For LLVM 16 (where pointers are always opaque) the second part of the |
We still default to non-opaque pointers with LLVM 16, as we aren't ready yet: #4261 |
Oh, in that case the cause of that assertion is Lines 589 to 590 in d4f2bed
isOpaque
|
Yep thx, that was it. |
The LLVM 16 bump is a PITA because of:
|
13f69f7
to
358761d
Compare
Wrt. the miscompile when compiling the frontend with LLVM 16, I've tried:
|
could the miscompile be because of typed pointers no longer being really supported by LLVM? |
Your guess is probably as good as mine, but I don't think so. |
Disabling the new function specializations has fixed the miscompile on Win64 at least; Mac still needs troubleshooting. |
66f0b82
to
fcc5fa7
Compare
macOS x64 is 'solved' too now (with LTO+PGO), after disabling the func specializations for the LTO plugin too. 2 important questions remain:
|
I will test soon. What is the flag to enable/disable the func specialization? |
Great! Nothing to build, just downlaod & extract CI artifact, then try compiling the failing module. The cross-compiled binary is either miscompiled (will crash or produce garbage) or works.
I'm using |
…and llvm::makeArrayRef()
In ldc2.conf for LDC itself, and in the linker cmdline for LTO plugins.
the macos arm64 artifact produces a little garbage indeed...
|
Alright, thx a lot for testing. |
[The CircleCI Mac jobs 'fail' because we've run out of credits.] |
Based on #4411.