Fix Unit tests under LLVM 11 #227
Merged
Conversation
This file contains hidden or 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
Per LLVM 10.0 release notes: "Unnamed function arguments now get printed with their automatically generated name (e.g. “i32 %0”) in definitions. This may require front-ends to update their tests; if so there is a script utils/add_argument_names.py that correctly converted 80-90% of Clang tests. Some manual work will almost certainly still be needed."
A recent version of LLVM removed implicit alignments from alloca, load, and store. This means that an "align n" must be present on those instructions, although one will be automatically generated by LLVMBuildAlloca and similar instructions. As part of this, LLVM changed the behavior of LLVMSetAlignment to wrap the alignment in an Align rather than a MaybeAlign. As a result, when an alignment 0 is explicitly set, LLVM assumes it is greater than 0 and takes the log2 of it. The shortcut algorithm for log2 (e.g. 31 - leading zero bit count) results in an overflow when the alignment is 0. This causes the module verifier to fail. Solution: Let the default alignment be calculated and don't explicitly set it when no explicit alignment is specified.
matthewseaman
force-pushed
the
llvm-11-tests
branch
from
c19d9a4 to
6446f13
Compare
segiddins
approved these changes
Feb 17, 2021
|
Still doing an audit of alignment usage. |
Guard against 0 and correct 64-bit log2 for 32-bit input
Putting 0 alignments in here goes against DWARF
matthewseaman
added a commit
that referenced
this pull request
Mar 26, 2021
This is consistent with changes in #227
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.
Resolves #225.
Two issues needed addressed.
Argument Auto-Generated Names
Per LLVM 10.0 release notes:
For example, IR that used to be:
becomes:
Solution: Update file check statements to include argument names.
Default Alignments
Couldn't find it mentioned in the release notes, but a recent LLVM seems to have changed the spec for
alloca,load, andstoresuch thatalignis now required to be specified in the IR with the alignment value. (See here.) Functions such asLLVMBuildAllocawill now auto-generate an alignment, although one can be explicitly specified viaLLVMSetAlignment.Unfortunately, with this change, calling
LLVMSetAlignmentwith an alignment of 0 is unsupported (this could be a bug in LLVM). When 0 is passed, internally LLVM now wraps it in anAlignrather than aMaybeAlignand does not perform a 0 check (see here.). Eventually,Log2is called on the alignment, and the shortcut for Log2 (e.g. 31 - leading zero bit count) results in an overflow of the unsigned integer. This causes a very large alignment value and module verification fails.Solution: Keep the generated alignment value from methods like
LLVMBuildAllocaand only explicit set one when non-zero.