- Feb 08, 2022
-
-
Dawid Jurczak authored
Among many FoldingSet users most notable seem to be ASTContext and CodeGenTypes. The reasons that we spend not-so-tiny amount of time in FoldingSet calls from there, are following: 1. Default FoldingSet capacity for 2^6 items very often is not enough. For PointerTypes/ElaboratedTypes/ParenTypes it's not unlikely to observe growing it to 256 or 512 items. FunctionProtoTypes can easily exceed 1k items capacity growing up to 4k or even 8k size. 2. FoldingSetBase::GrowBucketCount cost itself is not very bad (pure reallocations are rather cheap thanks to BumpPtrAllocator). What matters is high collision rate when lot of items end up in same bucket slowing down FoldingSetBase::FindNodeOrInsertPos and trashing CPU cache (as items with same hash are organized in intrusive linked list which need to be traversed). This change address both issues by increasing initial size of FoldingSets used in ASTContext and CodeGenTypes. Extracted from: https://reviews.llvm.org/D118385 Differential Revision: https://reviews.llvm.org/D118608
-
Benjamin Kramer authored
Static functions in a header cause spurious unused function warnings.
-
Jacques Pienaar authored
-
Bixia Zheng authored
Add a Python method, output_sparse_tensor, to use sparse_tensor.out to write a sparse tensor value to a file. Modify the method that evaluates a tensor expression to return a pointer of the MLIR sparse tensor for the result to delay the extraction of the coordinates and non-zero values. Implement the Tensor to_file method to evaluate the tensor assignment and write the result to a file. Add unit tests. Modify test golden files to reflect the change that TNS outputs now have a comment line and two meta data lines. Reviewed By: aartbik Differential Revision: https://reviews.llvm.org/D118956
-
Balazs Benics authored
This reverts commit 841817b1. Ah, it still fails on build bots for some reason. Pinning the target triple was not enough.
-
Mark de Wever authored
This avoids using an libc++ internal macro in our tests. Reviewed By: #libc, philnik, ldionne Differential Revision: https://reviews.llvm.org/D118874
-
Mark de Wever authored
This has been suggested in D117950. Reviewed By: ldionne, #libc, philnik Differential Revision: https://reviews.llvm.org/D118971
-
Andy Yankovsky authored
On Windows certain function from `Signals.h` require that `DbgHelp.dll` is loaded. This typically happens when the main program calls `llvm::InitLLVM`, however in some cases main program doesn't do that (e.g. when the application is using LLDB via `liblldb.dll`). This patch adds a safe guard to prevent crashes. More discussion in https://reviews.llvm.org/D119009. Reviewed By: aganea Differential Revision: https://reviews.llvm.org/D119181
-
Mircea Trofin authored
Added a `NoopSavedModelImpl` type which can be used as a mock AOT-ed saved model, and further minimize conditional compilation cases. This also removes unused function warnings on gcc.
-
Krzysztof Drewniak authored
The conversion to the new ControlFlow dialect didn't change the GPUToROCDL pass - this commit fixes this issue. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D119188
-
Hongtao Yu authored
Tracking optimized-away inlinees based on all probes in a binary is expansive in terms of memory usage I'm making the tracking on-demand based on profiled functions only. This saves about 10% memory overall for a medium-sized benchmark. Before: note: After parsePerfTraces note: Thu Jan 27 18:42:09 2022 note: VM: 8.68 GB RSS: 8.39 GB note: After computeSizeForProfiledFunctions note: Thu Jan 27 18:42:41 2022 note: **VM: 10.63 GB RSS: 10.20 GB** note: After generateProbeBasedProfile note: Thu Jan 27 18:45:49 2022 note: VM: 25.00 GB RSS: 24.95 GB note: After postProcessProfiles note: Thu Jan 27 18:49:29 2022 note: VM: 26.34 GB RSS: 26.27 GB After: note: After parsePerfTraces note: Fri Jan 28 12:04:49 2022 note: VM: 8.68 GB RSS: 7.65 GB note: After computeSizeForProfiledFunctions note: Fri Jan 28 12:05:26 2022 note: **VM: 8.68 GB RSS: 8.42 GB** note: After generateProbeBasedProfile note: Fri Jan 28 12:08:03 2022 note: VM: 22.93 GB RSS: 22.89 GB note: After postProcessProfiles note: Fri Jan 28 12:11:30 2022 note: VM: 24.27 GB RSS: 24.22 GB This should be a no-diff change in terms of profile quality. Reviewed By: wenlei Differential Revision: https://reviews.llvm.org/D118515
-
Mark de Wever authored
This change is a preparation for adapting the tests for P2216 std::format improvements Reviewed By: #libc, Quuxplusone, ldionne Differential Revision: https://reviews.llvm.org/D118717
-
Balazs Benics authored
Sometimes when I pass the mentioned option I forget about passing the parameter list for c++ sources. It would be also useful newcomers to learn about this. This patch introduces some logic checking common misuses involving `-analyze-function`. Reviewed-By: martong Differential Revision: https://reviews.llvm.org/D118690
-
Matt Arsenault authored
Previously would reuse the VGPR used for large frame offsets with the one needed for copying from the AGPR. Fix this by reusing the register we already reserved for handling AGPR to AGPR copies.
-
Philip Reames authored
PredicatedScalarEvolution has a predicate type for representing A == B. This change generalizes it into something which can represent a A <pred> B. This generality is currently unused, but is motivated by a couple of recent cases which have come up. In particular, I'm currently playing around with using this to simplify the runtime checking code in LoopVectorizer. Regardless of the outcome of that prototyping, generalizing the compare node seemed useful.
-
Nikita Popov authored
Alloca promotion can only deal with cases where the load/store types match the alloca type (it explicitly does not support bitcasted load/stores). With opaque pointers this is no longer enforced through the pointer type, so add an explicit check.
-
Matt Arsenault authored
We need to guarantee cheap copies between AGPRs, and unfortunately gfx908 cannot directly do this. Theoretically we could set the scavenger up with an emergency spill slot, but it also feels unreasonable to pay that cost for what was assumed to be a simple and cheap copy. Pick a register that doesn't conflict with any ABI registers. This does not address the same issue when copying from SGPR to AGPR for gfx90a (this coincidentally fixes it for gfx908), but that's less interesting since the register allocator shouldn't be proactively introducing such copies. One edge case I'm worried about is respecting the VGPR budget implied by amdgpu-waves-per-eu. If the theoretical upper bound of a function is 32 VGPRs, this will force the actual count to be 33. This is also broken if inline assembly uses/defs something in v32. The coalescer will eliminate the intermediate vreg between the def and use, and the introduced copy will clobber the user value. (cherry picked from commit 3335784ac2d587ff4eac04586e189532ae8b2607)
-
Matt Arsenault authored
-
Louis Dionne authored
This testing configuration links tests against one libc++ shared library, but runs them against another libc++ shared library. This makes sure that we can build applications against the libc++ provided in a recent SDK and back-deploy them to platforms containing older libc++ dylibs. It also switches the Apple CI script to using that new configuration instead of the legacy one. Differential Revision: https://reviews.llvm.org/D119195
-
zhijian authored
Summary: 1.added a helper function isSymbolDefined(). 2.Split out sorting code 3.refactor symbol comparing function Reviewers: James Henderson,Fangrui Song Differential Revision: https://reviews.llvm.org/D119028
-
Sanjay Patel authored
The test diffs are identical to D119111. This only affects x86 currently because no other target has an override for the TLI hook that controls this transform.
-
Nikita Popov authored
The code assumed that the upgrade would happen due to the argument count changing from 4 to 5. However, a remangling upgrade is also possible here.
-
David Sherwood authored
This patch adds custom lowering support for ISD::MUL with v1i64 and v2i64 types when SVE is enabled, regardless of the minimum SVE vector length. We do this because NEON simply does not have 64-bit vector multiplies, so we want to take advantage of these instructions in SVE. I've updated the 128-bit min SVE vector bits tests here: CodeGen/AArch64/sve-fixed-length-int-arith.ll CodeGen/AArch64/sve-fixed-length-int-mulh.ll CodeGen/AArch64/sve-fixed-length-int-rem.ll Differential Revision: https://reviews.llvm.org/D118802
-
Arjun P authored
Add support for computing an overapproximation of the number of integer points in a polyhedron. The returned result is actually the number of integer points one gets by computing the "rational shadow" obtained by projecting out the local IDs, finding the minimal axis-parallel hyperrectangular approximation of the shadow, and returning the number of integer points in that. This does not currently support symbols. Reviewed By: Groverkss Differential Revision: https://reviews.llvm.org/D119228
-
Roman Lebedev authored
https://godbolt.org/z/js9fTTG9h ^ we don't care what `isGuaranteedNotToBeUndefOrPoison()` says unless we already knew that the operands were equal.
-
Roman Lebedev authored
It checks IR after optimizations, which is inherently fragile, and the results are now different after the recent patch.
-
Arjun P authored
[MLIR][Presburger] Simplex::computeIntegerBounds: support unbounded directions by returning Optionals
-
Nathan Sidwell authored
a) Using a do...while loop in the number formatter means we do not have to special case zero. b) Let's use 'if (auto size = ...) {}' for appending to the output buffer. c) We should also be using memcpy there, not memmove -- the string being appended is never part of the current buffer. d) Let's put all the operator<< functions together. e) I find 'if (cond) frob(..., true) ; elseOD frob(..., false)' somewhat confusing. Let's just use std::abs in the signed integer printer and let CSE decide about the duplicate < 0 testing. f) Let's have as many as possible return *this. That's both more consistent, and allows tailcalls in some cases (the actual number formatter has a local array though). These changes removed around 100 bytes from the demangler's instructions on x86_64. Reviewed By: ChuanqiXu Differential Revision: https://reviews.llvm.org/D119176
-
Nikita Popov authored
Following the discussion on D118229, this marks all pointer-typed kernel arguments as having ABI alignment, per section 6.3.5 of the OpenCL spec: > For arguments to a __kernel function declared to be a pointer to > a data type, the OpenCL compiler can assume that the pointee is > always appropriately aligned as required by the data type. Differential Revision: https://reviews.llvm.org/D118894
-
Nikita Popov authored
Instead of using the pointer element type, look at how the pointer is actually being used in store instructions, while looking through bitcasts. This makes the transform compatible with opaque pointers and a bit more general. It's worth noting that I have dropped the 3-vector to 4-vector shufflevector special case, because this is now handled in a different way: If the value is actually used as a 4-vector, then we're directly going to use that type, instead of shuffling to a 3-vector in between. Differential Revision: https://reviews.llvm.org/D119237
-
Simon Pilgrim authored
[X86] selectLEAAddr - relax heuristic to only require one operand to be a MathWithFlags op (PR46809) As suggested by @craig.topper, relaxing LEA matching to only require the ADD to be fed from a single op with EFLAGS helps avoid duplication when the EFLAGS are consumed in a later, dependent instruction. There was some concern about whether the heuristic is too simple, not taking into account lost loads that can't fold by using a LEA, but some basic tests (included in select-lea.ll) don't suggest that's really a problem. Differential Revision: https://reviews.llvm.org/D118128
-
serge-sans-paille authored
Major user-facing changes: Many headers in llvm/DebugInfo/CodeView no longer include llvm/Support/BinaryStreamReader.h or llvm/Support/BinaryStreamWriter.h, those headers may need to be included manually. Several headers in llvm/DebugInfo/CodeView no longer include llvm/DebugInfo/CodeView/EnumTables.h or llvm/DebugInfo/CodeView/CodeView.h, those headers may need to be included manually. Some statistics: $ clang++ -E -Iinclude -I../llvm/include ../llvm/lib/DebugInfo/CodeView/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l after: 2794466 before: 2832765 Discourse thread on the topic: https://discourse.llvm.org/t/include-what-you-use-include-cleanup/ Differential Revision: https://reviews.llvm.org/D119092
-
Simon Pilgrim authored
[X86] Remove __builtin_ia32_padd/psub saturated intrinsics and use generic __builtin_elementwise_add/sub_sat D117898 added the generic __builtin_elementwise_add_sat and __builtin_elementwise_sub_sat with the same integer behaviour as the SSE/AVX instructions This patch removes the __builtin_ia32_padd/psub saturated intrinsics and just uses the generics - the existing tests see no changes: __m256i test_mm256_adds_epi8(__m256i a, __m256i b) { // CHECK-LABEL: test_mm256_adds_epi8 // CHECK: call <32 x i8> @llvm.sadd.sat.v32i8(<32 x i8> %{{.*}}, <32 x i8> %{{.*}}) return _mm256_adds_epi8(a, b); }
-
Nikita Popov authored
We currently don't have any specialized upgrades for intrinsics that can be used in invokes, but they can still be subject to a generic remangling upgrade. In particular, this happens when upgrading statepoint intrinsics under -opaque-pointers. This patch just changes the upgrade code to work on CallBase instead of CallInst in particular.
-
Joseph Huber authored
This patch enables running the new driver tests for AMDGPU. Previously this was disabled because some tests failed. This was only because the new driver tests hadn't been listed as unsupported or expected to fail. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D119240
-
Sanjay Patel authored
This is no-functional-change-intended because only the x86 target enables the TLI hook currently. We can add fmul/fdiv opcodes to the switch similar to the proposal D119111, but we don't need to make other changes like enabling target-specific combines. We can also add integer opcodes (add, or, shl, etc.) to the switch because this function is called from all of the generic binary opcodes. The goal is to incrementally enable the profitable diffs from D90113 while avoiding regressions. Differential Revision: https://reviews.llvm.org/D119150
-
Roman Lebedev authored
If the original invokes had uses, the uses must have been in PHI's, but that immediately results in the incoming values being incompatible. But we'll replace uses of the original invokes with the use of the merged invoke, so as long as the incoming values become compatible after that, we can merge.
-
Roman Lebedev authored
As long as the incoming values for all the invokes in the set are identical, we can merge the invokes.
-
Roman Lebedev authored
Even if the invokes have normal destination, iff it's the same block, we can merge them. For now, require that there are no PHI nodes, and the returned values of invokes aren't used.
-
Roman Lebedev authored
-