- Nov 19, 2020
-
-
Balázs Kéri authored
Do not warn for "pointer to aggregate" in a `sizeof(A) / sizeof(A[0])` expression if `A` is an array of pointers. This is the usual way of calculating the array length even if the array is of pointers. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D91543
-
Ji Kim authored
For intrinsics with multiple returns where one or more operands are overloaded, the overloaded type is inferred from the corresponding field of the resulting struct, instead of accessing the result directly. As such, the hasResult parameter of LLVM_IntrOpBase (and derived classes) is replaced with numResults. TableGen for intrinsics also updated to populate this field with the total number of results. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D91680
-
Simon Moll authored
This defines the vec_broadcast SDNode along with lowering and isel code. We also remove unused type mappings for the vector register classes (all vector MVTs that are not used in the ISA go). We will implement support for short vectors later by intercepting nodes with illegal vector EVTs before LLVM has had a chance to widen them. Reviewed By: kaz7 Differential Revision: https://reviews.llvm.org/D91646
-
Sam Clegg authored
Differential Revision: https://reviews.llvm.org/D91769
-
Andrew Wei authored
Some nested loops may share the same ExitingBB, so after we finishing FoldExit, we need to notify OuterLoop and SCEV to drop any stored trip count. Patched by: guopeilin Reviewed By: mkazantsev Differential Revision: https://reviews.llvm.org/D91325
-
Kadir Cetinkaya authored
-
Qiu Chaofan authored
According to ELF v2 ABI, both IEEE 128-bit and IBM extended floating point variables should be quad-word (16 bytes) aligned. Previously, only vector types are considered aligned as quad-word on PowerPC. This patch will fix incorrectness of IEEE 128-bit float argument in va_arg cases. Reviewed By: rjmccall Differential Revision: https://reviews.llvm.org/D91596
-
Siva Chandra Reddy authored
Targeted tests have been added. Reviewed By: lntue Differential Revision: https://reviews.llvm.org/D91752
-
Mircea Trofin authored
The lookup logic is also reusable. Also refactored the API to return the loaded vector - this makes it more clear what state it is in in the case of error (as it won't be returned). Differential Revision: https://reviews.llvm.org/D91759
-
Kazu Hirata authored
-
Mircea Trofin authored
It's generic for the 'development mode', not specific to the inliner case. Differential Revision: https://reviews.llvm.org/D91751
-
Craig Topper authored
Differential Revision: https://reviews.llvm.org/D91730
-
River Riddle authored
This prevents potential problems that occur when multiple pass managers register crash recovery contexts.
-
River Riddle authored
This allows for operations that exclusively affect symbol operations to better describe their side effects. Differential Revision: https://reviews.llvm.org/D91581
-
Kai Luo authored
-
Walter Erquinigo authored
Depends on D90490. The stop command is simple and invokes the new method Trace::StopTracingThread(thread). On the other hand, the start command works by delegating its implementation to a CommandObject provided by the Trace plugin. This is necessary because each trace plugin needs different options for this command. There's even the chance that a Trace plugin can't support live tracing, but instead supports offline decoding and analysis, which means that "thread trace dump instructions" works but "thread trace start" doest. Because of this and a few other reasons, it's better to have each plugin provide this implementation. Besides, I'm using the GetSupportedTraceType method introduced in D90490 to quickly infer what's the trace plug-in that works for the current process. As an implementation note, I moved CommandObjectIterateOverThreads to its header so that I can use it from the IntelPT plugin. Besides, the actual start and stop logic for intel-pt is not part of this diff. Reviewed By: clayborg Differential Revision: https://reviews.llvm.org/D90729
-
Chris Kennelly authored
This allows for matching the constructors std::string has in common with std::string_view. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D91015
-
Duncan P. N. Exon Smith authored
Support: Avoid SmallVector::assign with a range from to-be-replaced vector in Windows GetExecutableName This code wasn't valid, and 5abf76fb started asserting. This is a speculative fix since I don't have a Windows machine handy.
-
Duncan P. N. Exon Smith authored
2c196bbc asserted that `SmallVector::push_back` doesn't invalidate the parameter when it needs to grow. Do the same for `resize`, `append`, `assign`, `insert`, and `emplace_back`. Differential Revision: https://reviews.llvm.org/D91744
-
Aart Bik authored
Rationale: Make sure preconditions are tested already during verfication. Currently, the only way a sparse rewriting rule can fail is if (1) the linalg op does not have sparse annotations, or (2) a yet to be handled operation is encounted inside the op Reviewed By: penpornk Differential Revision: https://reviews.llvm.org/D91748
-
snek authored
Patch by snek Reviewed By: aheejin Differential Revision: https://reviews.llvm.org/D90978
-
Moritz Sichert authored
Reviewed By: csigg, dblaikie Differential Revision: https://reviews.llvm.org/D91183
-
Evgenii Stepanov authored
HwasanThreadList::DontNeedThread clobbers Thread::next_, Breaking the freelist. As a result, only the top of the freelist ever gets reused, and the rest of it is lost. Since the Thread object with its associated ring buffer is only 8Kb, this is typically only noticable in long running processes, such as fuzzers. Fix the problem by switching from an intrusive linked list to a vector. Differential Revision: https://reviews.llvm.org/D91392
-
Arthur Eubanks authored
It has been on by default for a couple months without complaint. Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D91743
-
Scott Linder authored
In some places the parser guards against dereferencing `End`, while in others it relies on the presence of a trailing `'\0'` to elide checks. Add the remaining guards needed to ensure the parser never attempts to dereference `End`, making it safe to not require a null-terminated input buffer. Update the parser fuzzer harness so that it tests with buffers that are guaranteed to be non-null-terminated, null-terminated, and 1-terminated, additionally ensuring the result of the parse is the same in each case. Some of the regression tests were written by inspection, and some are cases caught by the fuzzer which required additional fixes in the parser. Differential Revision: https://reviews.llvm.org/D84050
-
Scott Linder authored
This is essentially a clone of the existing fuzzer added in D50839, but for the whole parser Streamer, and currently only testing for sanitizer violations. Differential Revision: https://reviews.llvm.org/D91573
-
Kazushi (Jam) Marukawa authored
Add vmv intrinsic instructions and regression tests. Reviewed By: simoll Differential Revision: https://reviews.llvm.org/D91700
-
Jonas Devlieghere authored
Mangled::GetName and Mangled::GetDemangledName no longer take any arguments.
-
Vitaly Buka authored
Disable the test on old systems. pthread_cond_clockwait is supported by glibc-2.30. It also supported by Android api 30 even though we do not run tsan on Android. Fixes https://github.com/google/sanitizers/issues/1259 Reviewed By: dvyukov
-
Nico Weber authored
-
Diego Caballero authored
Refactoring/clean-up step needed to add support for producer-consumer fusion with multi-store producer loops and, in general, to implement more general loop fusion strategies in Affine. It introduces the following changes: - AffineLoopFusion pass now uses loop fusion utilities more broadly to compute fusion legality (canFuseLoops utility) and perform the fusion transformation (fuseLoops utility). - Loop fusion utilities have been extended to deal with AffineLoopFusion requirements and assumptions while preserving both loop fusion utilities and AffineLoopFusion current functionality within a unified implementation. 'FusionStrategy' has been introduced for this purpose and, in the future, it will allow us to have a single loop fusion core implementation that will produce different fusion outputs depending on the strategy used. - Improve separation of concerns for legality and profitability analysis: 'isFusionProfitable' no longer filters out illegal scenarios that 'canFuse' didn't detect, or the other way around. 'canFuse' now takes loop dependences into account to determine the fusion loop depth (producer-consumer fusion only). - As a result, maximal fusion now doesn't require any profitability analysis. - Slices are now computed only once and reused across the legality, profitability and fusion transformation steps (producer-consumer). - Refactor some utilities and remove redundant copies of them. This patch is NFCI and should preserve the existing functionality of both the AffineLoopFusion pass and the affine fusion utilities. Reviewed By: andydavis1, bondhugula Differential Revision: https://reviews.llvm.org/D90798 -
Richard Smith authored
be unique in its scope.
-
Hsiangkai Wang authored
@tangxingxin1008 found a bug that regard vadd.vv v1, v3, a0 as a valid V instruction. We should remove the VRegAsmOperand operand class and use VR register class directly. Patched by: tangxingxin1008, Hsiangkai Differential Revision: https://reviews.llvm.org/D91712
-
Louis Dionne authored
This commit makes it clear that the typeinfo comparison implementation is automatically selected by default, and that the CMake option only overrides the value. This has been a source of confusion and bugs ever since we've introduced complexity in that area, so I'm trying to simplify it while still allowing for some control on the implementation. Differential Revision: https://reviews.llvm.org/D91574
-
peter klausler authored
Fortran defines "null-init" null pointer initializers as being function references, syntactically, that have to resolve to calls to the intrinsic function NULL() with no actual arguments. Differential revision: https://reviews.llvm.org/D91657
-
Peter Steinfeld authored
When comparing LOGICAL operands using ".eq." or ".ne." we were not guiding users to the ".eqv." and ".neqv." operations. Differential Revision: https://reviews.llvm.org/D91736
-
Fangrui Song authored
MCExpr::evaluateAsRelocatableImpl : allow evaluation of non-VK_None MCSymbolRefExpr when MCAsmLayout is available https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4acf8c78e659833be8be047ba2f8561386a11d4b (1994) introduced this behavior: if a fixup symbol is equated to an expression with an undefined symbol, convert the fixup to be against the target symbol. glibc relies on this behavior to perform assembly level indirection ``` asm("memcpy = __GI_memcpy"); // from sysdeps/generic/symbol-hacks.h ... // call memcpy@PLT // The relocation references __GI_memcpy in GNU as, but memcpy in MC (without the patch) memcpy (...); ``` (1) It complements `extern __typeof(memcpy) memcpy asm("__GI_memcpy");` The frontend asm label does not redirect synthesized memcpy in the middle-end. (See D88712 for details) (2) `asm("memcpy = __GI_memcpy");` is in every translation unit, but the memcpy declaration may not be visible in the translation unit where memcpy is synthesized. MC already redirects `memcpy = __GI_memcpy; call memcpy` but not `memcpy = __GI_memcpy; call memcpy@plt`. This patch fixes the latter by allowing MCExpr::evaluateAsRelocatableImpl to evaluate a non-VK_None MCSymbolRefExpr, which is only done after the layout is available. GNU as allows `memcpy = __GI_memcpy+1; call memcpy@PLT` which seems nonsensical, so we don't allow it. `MC/PowerPC/pr38945.s` `NUMBER = 0x6ffffff9; cmpwi 8,NUMBER@l` requires the `symbol@l` form in AsmMatcher, so evaluation needs to be deferred. This is the place whether future simplification may be possible. Note, if we suppress the VM_None evaluation when MCAsmLayout is nullptr, we may lose the `invalid reassignment of non-absolute variable` diagnostic (`ARM/thumb_set-diagnostics.s` and `MC/AsmParser/variables-invalid.s`). We know that this diagnostic is troublesome in some cases (https://github.com/ClangBuiltLinux/linux/issues/1008), so we can consider making simplification in the future. Reviewed By: jyknight Differential Revision: https://reviews.llvm.org/D88625
-
Arthur Eubanks authored
This matches the legacy AA infra and fixes llvm/test/ANalysis/TypeBasedAliasAnalysis/precedence.ll under NPM.
-
Kostya Kortchinsky authored
This modifies the tests so that they can be run on Fuchsia: - add the necessary includes for `set`/`vector` etc - do the few modifications required to use zxtest instead og gtest `backtrace.cpp` requires stacktrace support that Fuchsia doesn't have yet, and `enable_disable.cpp` currently uses `fork()` which Fuchsia doesn't support yet. I'll revisit this later. I chose to use `harness.h` to hold my "platform-specific" include and namespace, and using this header in tests rather than `gtest.h`, which I am open to change if someone would rather go another direction. Differential Revision: https://reviews.llvm.org/D91575
-
https://nuttx.apache.orgXiang Xiao authored
Since NuttX conform to POSIX standard, the code need to add is very simple. Differential Revision: https://reviews.llvm.org/D88718
-