Upgrade to LLVM 14 #12001
Merged
Upgrade to LLVM 14 #12001
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
upstream commit 91632c8ac97fa3daffe4ff8f1391735b5d6805e6
upstream commit 91632c8ac97fa3daffe4ff8f1391735b5d6805e6
* zig_clang is fully updated * zig_llvm is fully updated Some initial work on codegen.cpp is in place for upgrading to LLVM's new opaque pointers. However there is much more to be done. A few of zig llvm bindings for deprecated functions have been updated; more need to be updated.
LLVM 14 deprecated a bunch of C API functions in preparation for opaque pointer changes. However, they did not actually implement opaque pointer semantics, so the deprecations are largely masturbatory. I have nothing against masturbation, I am just busy trying to get the self hosted compiler done for 0.10.0, so we will come back to this later.
LLVM pointers are transitioning to no longer have types, however, inline assembly inputs and outputs which accept pointers need to know the element type. So, inline assembly must be upgraded to add elementtype(<ty>) annotations.
Notable changes: `_i386`, `_i486`, and `_i686` are renamed to `i386`, `i486`, and `i686` respectively. `std.zig.fmtId` is enhanced to support formatting `i386` as `@"i386"`. Some CPU features which are actually CPU models have been properly flattened, such as `apple_a12`, `apple_a13`, `apple_a7`, `cortex_a78c`, `exynos_m4`, `neoverse_e1`, `neoverse_n1`, `neoverse_n2`, `neoverse_v1`. Some CPU features have been added and some have been removed, following LLVM's lead. CSky CPU features support is added.
integer types are valid ids; we need different logic inside the update_cpu_features tool, not to change the fmtId function.
This file contains build configuration options which zig instead provides via command line flags.
It appears that libcxx files now want to additionally include based from the src/ directory.
This is the equivalent of d19290e applied to stage2 instead of stage1.
LLVM 14 makes it so that a RHS of saturating shift left produces a poison value if the value is greater than the number of bits of the LHS. Zig now emits code that will check if this is the case and select a saturated LHS value in such case, matching Zig semantics.
This follows LLVM14's lead on vector alignment, which computes byte count based on the length premultiplied by bits. This commit also disables behavior tests regressed by LLVM 14, only for stage1. stage2 fortunately does not trip the regression.
stage2 already has this fixed; debug info is given size in bits rather than ABI size (bytes) multiplied by 8. closes #11587
LLVM 14 optimizes differently, so it's reasonable to have there be a binary difference here.
This was referenced Jul 6, 2022
That issue is 😆 |
The previous tarballs were stage3 which is not quite ready for primetime yet.
This is intended to fix this error: lld-link: error: undefined symbol: _GUID const& __mingw_uuidof<IEnumSetupInstances>() >>> referenced by D:\a\1\s\src\windows_com.hpp:898 >>> D:\a\1\s\zig-cache\o\a5030d467932f0ce2f6511feb7d6af12\windows_sdk.obj:(__IEnumSetupInstances_IID_getter()) Thank you to Martin Storsjö for suggesting the fix.
|
Here is one performance data point, building Tetris from source: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Does not contain a workaround for llvm/llvm-project#55522, which means that using
@Vectorwithboolwill be regressed after merging this, until the upstream bug is fixed, probably in LLVM 15.0.0. The good news however is that the way stage2 lowers code in the LLVM backend makes the bug less likely to be triggered. In the future we will do better at staying on top of LLVM release candidates in order to report such issues and file them as release blockers.Other than this, things seem to be working fine.I noticed that even in master branch, the zig test suite does not run assertion-clean against a debug build of LLVM 13. My next priority will be to remedy this, and then follow it up with running the full test suite again, this time with LLVM 14 debug mode, to check for assertions tripped.Closes #11274