- Sep 10, 2021
-
-
Krasimir Georgiev authored
A follow-up to https://github.com/llvm/llvm-project/commit/f6bc614546e169bb1b17a29c422ebace038e6c62 where we handle the case where the semicolon is followed by a trailing comment. Reviewed By: MyDeveloperDay Differential Revision: https://reviews.llvm.org/D107907 (cherry picked from commit 0fc27ef1)
-
Krasimir Georgiev authored
https://reviews.llvm.org/D105964 updated the detection of function definitions. It had the unfortunate effect to start marking object definitions with attribute-like macros as function definitions. This addresses this issue. Reviewed By: owenpan Differential Revision: https://reviews.llvm.org/D107269 (cherry picked from commit f6bc6145)
-
Fraser Cormack authored
This patch fixes a variety of crashes resulting from the `MemCpyOptPass` casting `TypeSize` to a constant integer, whether implicitly or explicitly. Since the `MemsetRanges` requires a constant size to work, all but one of the fixes in this patch simply involve skipping the various optimizations for scalable types as cleanly as possible. The optimization of `byval` parameters, however, has been updated to work on scalable types in theory. In practice, this optimization is only valid when the length of the `memcpy` is known to be larger than the scalable type size, which is currently never the case. This could perhaps be done in the future using the `vscale_range` attribute. Some implicit casts have been left as they were, under the knowledge they are only called on aggregate types. These should never be scalably-sized. Reviewed By: nikic, tra Differential Revision: https://reviews.llvm.org/D109329 (cherry-picked from commit 7fb66d40)
-
Pushpinder Singh authored
Following nvptx approach, this patch uses complex function definitions from complex_cmath.h. With this patch, ovo passes 23/34 complex mathematical test cases. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D109344 (cherry picked from commit 12dcbf91)
-
Bradley Smith authored
When lowering a fixed length gather/scatter the index type is assumed to be the same as the memory type, this is incorrect in cases where the extension of the index has been folded into the addressing mode. For now add a temporary workaround to fix the codegen faults caused by this by preventing the removal of this extension. At a later date the lowering for SVE gather/scatters will be redesigned to improve the way addressing modes are handled. As a short term side effect of this change, the addressing modes generated for fixed length gather/scatters will not be optimal. Differential Revision: https://reviews.llvm.org/D109145 (cherry picked from commit 14e1a4a6)
-
Bjorn Pettersson authored
As part of the nontrivial unswitching we could end up removing child loops. This patch add a notification to the pass manager when that happens (using the markLoopAsDeleted callback). Without this there could be stale LoopAccessAnalysis results cached in the analysis manager. Those analysis results are cached based on a Loop* as key. Since the BumpPtrAllocator used to allocate Loop objects could be resetted between different runs of for example the loop-distribute pass (running on different functions), a new Loop object could be created using the same Loop pointer. And then when requiring the LoopAccessAnalysis for the loop we got the stale (corrupt) result from the destroyed loop. Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D109257 (fixes PR51754) (cherry-picked from commit 0f0344dd)
-
- Sep 09, 2021
-
-
serge-sans-paille authored
Setting -fvisibility=hidden when compiling Target libs has the advantage of not being intrusive on the codebase, but it also sets the visibility of all functions within header-only component like ADT. In the end, we end up with some symbols with hidden visibility within llvm dylib (through the target libs), and some with external visibility (through other libs). This paves the way for subtle bugs like https://reviews.llvm.org/D101972 This patch explicitly set the visibility of some classes to `default` so that `llvm::Any` related symbols keep a `default` visibility. Indeed a template function with `default` visibility parametrized by a type with `hidden` visibility is granted `hidden` visibility, and we don't want this for the uniqueness of `llvm::Any::TypeId`. Differential Revision: https://reviews.llvm.org/D108943
-
Cullen Rhodes authored
Also fixes a warning mentioned in D109359. Reviewed By: sdesmalen Differential Revision: https://reviews.llvm.org/D109363 (cherry picked from commit 89786c2b)
-
Chen Zheng authored
This causes https://bugs.llvm.org/show_bug.cgi?id=51714 and is not a right patch according to comments in D91724 This reverts commit 42eaf4fe. (cherry picked from commit 34badc40)
-
Matheus Izvekov authored
See PR48617. When assigning the new template arguments to the new TypeLoc, we were looping on the argument count of the original TypeLoc instead of the new one, which can be different when packs are present. Signed-off-by:
Matheus Izvekov <mizvekov@gmail.com> Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D109406 (cherry picked from commit 68b9d8ed)
-
Jonas Paulsson authored
In case of a virtual register tied to a phys-def, the register class needs to be computed. Make sure that this works generally also with fast regalloc by using TLI.getRegClassFor() whenever possible, and make only the case of 'Untyped' use getMinimalPhysRegClass(). Fixes https://bugs.llvm.org/show_bug.cgi?id=51699. Review: Ulrich Weigand Differential Revision: https://reviews.llvm.org/D109291 (cherry picked from commit 118997d8)
-
- Sep 08, 2021
-
-
Maksim Panchenko authored
Print relocations interleaved with disassembled instructions for executables with relocatable sections, e.g. those built with "-Wl,-q". Differential Revision: https://reviews.llvm.org/D109016 (cherry picked from commit 6300e4ac)
-
Hans Wennborg authored
so that it gets installed in LLVM_INSTALL_TOOLCHAIN_ONLY builds, such as used by the Windows installer. Differential revision: https://reviews.llvm.org/D109358 (cherry picked from commit c364dcbf)
-
Kadir Cetinkaya authored
This was an accidental behaviour change in D106789 and this patch restores it back to original state. Differential Revision: https://reviews.llvm.org/D109361 (cherry picked from commit 73c00d40)
-
David Truby authored
The isEssentiallyExtractHighSubvector function currently calls getVectorNumElements on a type that in specific cases might be scalable. Since this function only has correct behaviour at the moment on scalable types anyway, the function can just return false when given a fixed type. Differential Revision: https://reviews.llvm.org/D109163 (cherry picked from commit b297531e)
-
Gulfem Savrun Yeniceri authored
In the raw profile, binary ids immediately follow the header so when computing counters offset we need to account for the new section. (cherry picked from commit 8111f2f7)
-
Saleem Abdulrasool authored
Add missing break statements identified by static analysis tools. Patch by Andrii Kurdiumov! Reviewed By: compnerd, danielkiss Differential Revision: https://reviews.llvm.org/D107537 (cherry picked from commit 08a5ac36)
-
Nikita Popov authored
Due to a typo, this replaced %x with umax(C1, umin(C2, %x + C3)) rather than umax(C1, umin(C2, %x)). This didn't make a difference for the existing tests, because the result is only used for range calculation, and %x will usually have an unknown starting range, and the additional offset keeps it unknown. However, if %x already has a known range, we may compute a result range that is too small. (cherry picked from commit 8d54c8a0)
-
Sanjay Patel authored
The test is based on a miscompile example in: https://llvm.org/PR51321 Differential Revision: https://reviews.llvm.org/D107692 (cherry picked from commit e1e4bf17)
-
Yunde Zhong authored
(cherry picked from commit 9790a2a7)
-
Brad Smith authored
(cherry picked from commit bce178a5)
-
Brad Smith authored
(cherry picked from commit d8cd7806)
-
Richard Smith authored
Per the contract of ReadLateParsedTemplates, we should not be returning the same results multiple times. No functionality change intended, other than to runtime. Thanks to Luboš Luňák for identifying the cause of the regression! (cherry picked from commit 6eda66b0)
-
Matheus Izvekov authored
See PR51708. Attempting copy elision in dependent contexts with invalid variable, such as a variable with incomplete type, would cause a crash when attempting to calculate it's alignment. The fix is to just skip this optimization on invalid VarDecl, as otherwise this provides no benefit to error recovery: This functionality does not try to diagnose anything, it only calculates a flag which will affect where the variable will be allocated during codegen. Signed-off-by:
Matheus Izvekov <mizvekov@gmail.com> Reviewed By: rtrieu Differential Revision: https://reviews.llvm.org/D109191 (cherry picked from commit d98c34f4)
-
Brad Smith authored
(cherry picked from commit 775ab780)
-
Brad Smith authored
(cherry picked from commit b989662e)
-
Frederic Cambus authored
Differential Revision: https://reviews.llvm.org/D109244 (cherry picked from commit 466451c6)
-
- Sep 06, 2021
-
-
Andrzej Warzynski authored
Differential Revision: https://reviews.llvm.org/D109317
-
- Sep 04, 2021
-
-
Joachim Protze authored
In some build configurations, the target we depend on is not available for declaring the build dependency. We only need to declare the build dependency, if the build target is available in the same build. Fixes the issue raised in https://reviews.llvm.org/D107156#2969862 This patch should go into release/13 together with D108404 Differential Revision: https://reviews.llvm.org/D108868 (cherry picked from commit 5ea1c371)
-
Joachim Protze authored
D107156 and D107320 are not sufficient when OpenMP is built as llvm runtime (LLVM_ENABLE_RUNTIMES=openmp) because dependencies only work within the same cmake instance. We could limit the dependency to cases where libomptarget/plugins are really built. But compared to the whole llvm project, building openmp runtime is negligible and postponing the build of OpenMP runtime after the dependencies are ready seems reasonable. The direct dependency introduced in D107156 and D107320 is necessary for the case where OpenMP is built as llvm project (LLVM_ENABLE_PROJECTS=openmp). Differential Revision: https://reviews.llvm.org/D108404 (cherry picked from commit 4bb36df1)
-
Fraser Cormack authored
This patch fixes an issue where RISCV's `findCommutedOpIndices` would incorrectly return the pseudo `CommuteAnyOperandIndex` as a commutable operand index, rather than fixing a specific index. Reviewed By: rogfer01 Differential Revision: https://reviews.llvm.org/D108206 (cherry picked from commit 5b06cbac)
-
Amy Kwan authored
[libc++][NFC] Mark values in gdb pretty print comparison functions as live to prevent values being optimized out. It appears when testing LLVM 13 on Power, we run into failures with the `libcxx/test/libcxx/gdb/gdb_pretty_printer_test.sh.cpp` test case optimizing values out. Despite some the functions in the test already being marked with optnone, adding the `MarkAsLive()` calls inside of the pretty printer comparison functions resolves the issues of the values being optimized out. This patch aims to address https://llvm.org/PR51675. Differential Revision: https://reviews.llvm.org/D109204 (cherry picked from commit 217c6d64)
-
- Sep 03, 2021
-
-
Stefan Gränitz authored
These tests rely on running IR code with an explicit x86_64 target triple. They won't work on other architectures. (They won't work for 32-bit processes on x86_64 hosts either. We will take care of this later.) Differential Revision: https://reviews.llvm.org/D107640 (cherry picked from commit c5ab55f5)
-
Petr Hosek authored
When a nodeduplicate COMDAT group contains a weak symbol, choose a non-weak symbol (or one of the weak ones) rather than reporting an error. This should address issue PR51394. With the current IR representation, a generic comdat nodeduplicate semantics is not representable for LTO. In the linker, sections and symbols are separate concepts. A dropped weak symbol does not force the defining input section to be dropped as well (though it can be collected by GC). In the IR, when a weak linkage symbol is dropped, its associate section content is dropped as well. For InstrProfiling, which is where ran into this issue in PR51394, the deduplication semantic is a sufficient workaround. Differential Revision: https://reviews.llvm.org/D108689
-
- Sep 02, 2021
-
-
Arthur Eubanks authored
Per https://lists.llvm.org/pipermail/llvm-dev/2021-August/152305.html. Reviewed By: MaskRay, fhahn Differential Revision: https://reviews.llvm.org/D109080 (cherry picked from commit 2413d606)
-
Johannes Doerfert authored
Reference types in the return or parameter position did cause the OpenMP declare variant overload reasoning to give up. We should allow them as we allow any other type. This should fix the bug reported on the mailing list: https://lists.llvm.org/pipermail/openmp-dev/2021-August/004094.html Reviewed By: ABataev, pdhaliwal Differential Revision: https://reviews.llvm.org/D108774 (cherry picked from commit 2930c839)
-
Nikita Popov authored
This is a followup to D96780 to add one more pass missing from the NewPM LTO pipeline. The missing ArgPromotion run is inserted at the same position as in the LegacyPM, resolving the already present FIXME: https://github.com/llvm/llvm-project/blob/16086d47c0d0cd08ffae8e69a69c88653e654d01/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp#L1096-L1098 The compile-time impact is minimal with ~0.1% geomean regression on CTMark. Differential Revision: https://reviews.llvm.org/D108866 (cherry picked from commit b28c3b9d)
-
Philip Reames authored
This is a bailout for pr51680. This pass appears to assume that the alignment operand to an align tag on an assume bundle is constant. This doesn't appear to be required anywhere, and clang happily generates non-constant alignments for cases such as this case taken from the bug report: // clang -cc1 -triple powerpc64-- -S -O1 opal_pci-min.c extern int a[]; long *b; long c; void *d(long, int *, int, long, long, long) __attribute__((__alloc_align__(6))); void e() { b = d(c, a, 0, 0, 5, c); b[0] = 0; } This was exposed by a SCEV change which allowed a non-constant alignment to reach further into the pass' code. We could generalize the pass, but for now, let's fix the crash. (cherry picked from commit 9b45fd90)
-
- Sep 01, 2021
-
-
Sylvestre Ledru authored
-
Sylvestre Ledru authored
Differential Revision: https://reviews.llvm.org/D109023
-