-
Notifications
You must be signed in to change notification settings - Fork 793
LLVM and SPIRV-LLVM-Translator pulldown (WW45) #2717
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
Merged
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
For a diagnostic `A refers to B` where B refers to a bitcode file, if the symbol gets optimized out, the user may see `A refers to <internal>`; if the symbol is retained, the user may see `A refers to lto.tmp`. Save the reference InputFile * in the DenseMap so that the original filename is available in reportBackrefs().
…r lowering Move the code which adjusts the immediate/predicate on a G_ICMP to AArch64PostLegalizerLowering. This - Reduces the number of places we need to test for optimized compares in the selector. We know that the compare should have been simplified by the time it hits the selector, so we can avoid testing this in selects, brconds, etc. - Allows us to potentially fold more compares (previously, this optimization was only done after calling `tryFoldCompare`, this may allow us to hit some more TST cases) - Simplifies the selection code in `emitIntegerCompare` significantly; we can just use an emitSUBS function. - Allows us to avoid checking that the predicate has been updated after `emitIntegerCompare`. Also add a utility header file for things that may be useful in the selector and various combiners. No need for an implementation file at this point, since it's just one constexpr function for now. I've run into a couple cases where having one of these would be handy, so might as well add it here. There are a couple functions in the selector that can probably be factored out into here. Differential Revision: https://reviews.llvm.org/D89823
…nary/WriterExtBinary to their parent classes. SampleProfileReaderExtBinary/SampleProfileWriterExtBinary specify the typical section layout currently used by SampleFDO. Currently a lot of section reader/writer stay in the two classes. However, as we expect to have more types of SampleFDO profiles, we hope those new types of profiles can share the common sections while configuring their own sections easily with minimal change. That is why I move some common stuff from SampleProfileReaderExtBinary/SampleProfileWriterExtBinary to SampleProfileReaderExtBinaryBase/SampleProfileWriterExtBinaryBase so new profiles class inheriting from the base class can reuse them. Differential Revision: https://reviews.llvm.org/D89524
In 5d79664, we stopped looking at the LIBCXXABI_LIBCXX_INCLUDES variable, which broke users of the Standalone build. This patch reinstates that variable, however it must point to the *installed* path of the libc++ headers, not the libc++ headers in the source tree (which has always been the case, but wasn't enforced before). If LIBCXXABI_LIBCXX_INCLUDES points to the libc++ headers in the source tree, the `__config_site` header will fail to be found.
FieldDecl is an unamed bitfield. Unnamed bitfields aren't non-static data member, so such a bitfield isn't actually the first non-static data member.
… BB" This reverts commit adfb541. This is reverted because it caused an chrome error: https://crbug.com/1140168
`size_t` has different width on 32- and 64-bit architecture, but the computation to floor to power of two assumed it is 64-bit, which can cause an integer overflow. In this patch, architecture detection is added so that the operation for 64-bit `size_t`. Thank Luke for reporting the issue. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D89878
…, NFC Add helpers `getSLocEntryOrNull`, which handles the `Invalid` logic around `getSLocEntry`, and `getSLocEntryForFile`, which also checks for `SLocEntry::isFile`, and use them to reduce repeated code. Differential Revision: https://reviews.llvm.org/D89503
`SourceManager::isMainFile` does not use the filename, so it doesn't need the full `FileEntryRef`; in fact, it's misleading to take the name because that makes it look relevant. Simplify the API, and in the process remove some calls to `FileEntryRef::FileEntryRef` in the unit tests (which were blocking making that private to `SourceManager`). Differential Revision: https://reviews.llvm.org/D89507
An alwaysinline function may not get inlined in inliner-wrapper due to the inlining order. Previously for the following, the inliner would first inline @A() into @b(), ``` define void @A() { entry: call void @b() ret void } define void @b() alwaysinline { entry: br label %for.cond for.cond: call void @A() br label %for.cond } ``` making @b() recursive and unable to be inlined into @A(), ending at ``` define void @A() { entry: call void @b() ret void } define void @b() alwaysinline { entry: br label %for.cond for.cond: call void @b() br label %for.cond } ``` Running always-inliner first makes sure that we respect alwaysinline in more cases. Fixes https://bugs.llvm.org/show_bug.cgi?id=46945. Reviewed By: davidxl, rnk Differential Revision: https://reviews.llvm.org/D86988
*fingers crossed*
LD64 emits string tables which start with a space and a zero byte. This diff adjusts StringTableBuilder for linked Mach-O binaries to match LD64's behavior. Test plan: make check-all Differential revision: https://reviews.llvm.org/D89561
`SourceManager::getFileEntryRefForID`'s remaining callers just want the filename component, which is coming from the `FileInfo`. Replace the API with `getNonBuiltinFilenameForID`, which also removes another use of `FileEntryRef::FileEntryRef` outside of `FileManager`. Both callers are collecting file dependencies, and one of them relied on this API to filter out built-ins (as exposed by clang/test/ClangScanDeps/modules-full.cpp). It seems nice to continue providing that service. Differential Revision: https://reviews.llvm.org/D89508
The devirtualization wrapper misses cases where if it wraps a pass manager, an individual pass may devirtualize an indirect call created by a previous pass. For example, inlining may create a new indirect call which is devirtualized by instcombine. Currently the devirtualization wrapper will not see that because it only checks cgscc edges at the very beginning and end of the pass (manager) it wraps. This fixes some tests testing this exact behavior in the legacy PM. This piggybacks off of updateCGAndAnalysisManagerForPass()'s detection of promoted ref to call edges. This supercedes one of the previous mechanisms to detect devirtualization by keeping track of potentially promoted call instructions via WeakTrackingVHs. There is one more existing way of detecting devirtualization, by checking if the number of indirect calls has decreased and the number of direct calls has increased in a function. It handles cases where calls to functions without definitions are promoted, and some tests rely on that. LazyCallGraph doesn't track edges to functions without definitions so this part can't be removed in this change. check-llvm and check-clang with -abort-on-max-devirt-iterations-reached on by default doesn't show any failures outside of tests specifically testing it so it doesn't needlessly rerun passes more than necessary. (The NPM -O2/3 pipeline run the inliner/function simplification pipeline under a devirtualization repeater pass up to 4 times by default). Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D89587
… DWARF signatures
Now there are two main classes in Value hierarchy, which support metadata, these are Instruction and GlobalObject. They implement different APIs for metadata manipulation, which however overlap. This change moves metadata manipulation code into Value, so descendant classes can use this code for their operations on metadata. No functional changes intended. Differential Revision: https://reviews.llvm.org/D67626
The UtilityFunction ctor was dropping the text argument. Probably for that reason ClangUtilityFunction was setting the parent's member directly instead of deferring to the parent ctor. Also change the signatures to take strings which are std::moved in place.
The runtimes build was lying to the various runtimes builds by setting XXX_STANDALONE_BUILD=ON when they are really not being built standalone. Only COMPILER_RT_STANDALONE_BUILD appears to be necessary, but setting it for the other runtimes actually breaks everything. Differential Revision: https://reviews.llvm.org/D90005
g_expression_prefix, as the name implies, must be perfixed, not suffixed.
We want to have a caching version of symbolic BE exit count rather than recompute it every time we need it. Differential Revision: https://reviews.llvm.org/D89954 Reviewed By: nikic, efriedma
No support for relaxation yet -- this will always use the GOT entry.
…location." This reverts commit e2fceec. This commit broke one of the bots. Reverting while I investigate.
This diff refactors the code which determines the tool type based on how llvm-objcopy is invoked (objcopy vs strip vs bitcode-strip vs install-name-tool). NFC. Test plan: make check-all Differential revision: https://reviews.llvm.org/D89713
When switching the register debug operands to $noreg in setupDebugValueUndef() also clear the sub-register indices for virtual registers. This is done when marking DBG_VALUEs undef in other cases, e.g. in LiveDebugVariables. I have not found any cases where leaving the sub-register index causes any issues, and the indices would eventually get dropped when LiveDebugVariables reinserted the undef DBG_VALUEs after register scheduling, but if nothing else it looked a bit weird in printouts to have sub-register indices on $noreg, and I don't think the sub-register index holds any meaningful information at that point. I have not been able to find any source-level reproducer for this with an upstream target, so I have just added an instrumented machine-sink test. Reviewed By: djtodoro, jmorse Differential Revision: https://reviews.llvm.org/D89941
Use isKnownXY comparators when one of the operands can be with scalable vectors or getFixedSize() for all the other cases. This patch also does bug fixes for getPrimitiveSizeInBits by using getFixedSize() near the places with the TypeSize comparison. Differential Revision: https://reviews.llvm.org/D89703
If no pal metadata is given, default to the msgpack format instead of the legacy metadata. This makes tests better readable. Differential Revision: https://reviews.llvm.org/D90035
This patch adds a remarks that provides counts for each opcode per basic block. An snippet of the generated information can be seen below. The current implementation uses the target specific opcode for the counts. For example, on AArch64 this means we currently get 2 entries for `add` instructions if the block contains 32 and 64 bit adds. Similarly, immediate version are treated differently. Unfortunately there seems to be no convenient way to get only the mnemonic part of the instruction as a string AFAIK. This could be improved in the future. ``` --- !Analysis Pass: asm-printer Name: InstructionMix DebugLoc: { File: arm64-instruction-mix-remarks.ll, Line: 30, Column: 30 } Function: foo Args: - String: 'BasicBlock: ' - BasicBlock: else - String: "\n" - String: INST_MADDWrrr - String: ': ' - INST_MADDWrrr: '2' - String: "\n" - String: INST_MOVZWi - String: ': ' - INST_MOVZWi: '1' ``` Reviewed By: anemet, thegameg, paquette Differential Revision: https://reviews.llvm.org/D89892
Add VADD/VADS/VADX/VSUB/VSBS/VSBX/VMPY/VMPS/VMPX/VMPD/VDIV/VDVS/VDVX instructions. Also add regression tests. Reviewed By: simoll Differential Revision: https://reviews.llvm.org/D89642
Add VCMP/VCPS/VCPX/VCMS/VCMX vector instructions. Also add regression tests. Reviewed By: simoll Differential Revision: https://reviews.llvm.org/D89643
…ments. This allows using annotation in a much more contexts than it currently has. especially when annotation with template or constexpr. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D88645
CONFLICT (content): Merge conflict in llvm/include/llvm/InitializePasses.h
CONFLICT (content): Merge conflict in clang/test/CodeGen/annotations-field.c CONFLICT (content): Merge conflict in clang/lib/CodeGen/CodeGenFunction.cpp
…8645 Signed-off-by: Dmitry Sidorov <dmitry.sidorov@intel.com>
Spec can be found at intel#1612
It is possible that instruction has metadata operand which is actually is a constant expression which should be lowered, for example constant expression metadata can appear as operand of debug instruction.
Moved all tests for llvm intrinsics into a separate folder Moved some negative tests into corresponding directory
Enabled warnings as errors to clarify that most of enabled checks are required. New feature: warnings and errors found by clang-tidy are now being reported as annotations at "Files changed" page.
Signed-off-by: Dmitry Sidorov <dmitry.sidorov@intel.com>
/summary:run |
jsji
pushed a commit
that referenced
this pull request
Sep 21, 2024
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.
LLVM: llvm/llvm-project@d3205bb
SPIRV-LLVM-Translator: KhronosGroup/SPIRV-LLVM-Translator@d606b72