- Mar 10, 2021
-
-
Nathan James authored
Just looks nicer and easier to read. Reviewed By: kadircet Differential Revision: https://reviews.llvm.org/D98274
-
Alex Lorenz authored
This is useful for APIs that want to produce an attributed NSString as a result of some formatting API call.
-
Mehdi Amini authored
Also move setters out-of-line to make sure the templated helper is actually instantiated.
-
Albion Fung authored
This pull request implements patterns to exploit the load rightmost vector element instructions for loading element 0 on little endian PowerPC subtargets into v8i16 and v16i8 vector registers for i16 and i8 data types. Differential Revision: https://reviews.llvm.org/D94816#inline-921403
-
Juneyoung Lee authored
This reverts commit 07c3b97e due to a reported failure in two-stage build.
-
Fangrui Song authored
This is a minor issue because the TargetValue parameter of `__llvm_profile_instrument_memop` is usually small and cannot exceed 2**31 at all. Differential Revision: https://reviews.llvm.org/D97640
-
Philip Reames authored
-
Philip Reames authored
This was suggested by lebedev.ri over on D96534. You'll note lack of tests. During review, we weren't actually able to find a case which exercises it, but both I and lebedev.ri feel it's a reasonable change, straight forward, and near free. Differential Revision: https://reviews.llvm.org/D97064
-
Peter Steinfeld authored
We have a "<" operator defined on the type semantics::Symbol that's based on the symbols' locations in the cooked character stream. This is potentially problematic when comparing symbols from .mod files when the cooked character streams themselves might be allocated to varying memory locations. This change fixes that by using the order in which symbols are created as the basis for the "<" operator. Thanks to Tim and Peter for consultation on the necessity of doing this and the idea for what to use as the basis of the sort. This change in the "<" operator changed the expected results for three of the tests. I manually inspected the new results, and they look OK to me. The differences in data05.f90 and typeinfo01.f90 are entirely the order, offsets, and sizes of the derived type components. The changes in resolve102.f90 are due to the new, different "<" operator used for sorting. Differential Revision: https://reviews.llvm.org/D98225
-
Florian Hahn authored
This patch adds a few tests for memset/memcyp with non-constant size values. Some of the tests will be optimized in further patches.
-
Douglas Yung authored
Add requirement for aarch64-registered-target to test change added in 42e3f97a.
-
George Balatsouras authored
This removes hard-coded shadow width references and adds more RUN lines to increase test coverage under different options (fast16 labels mode). Also, shortens the test by unifying common lines under both combine- and no-combine-ptr-label options. Reviewed By: stephan.yichao.zhao Differential Revision: https://reviews.llvm.org/D98227
-
Fangrui Song authored
This reverts commit c11ff4bb & df67d352. Trying to make the change to the driver to avoid round-trip issues.
-
Fangrui Song authored
-
Christian Sigg authored
Provide default for gpuBinaryAnnotation so that we don't need to specify it in tests. The annotation likely only needs to be target specific if we want to lower to e.g. both CUDA and ROCDL. Reviewed By: herhut, bondhugula Differential Revision: https://reviews.llvm.org/D98168
-
Aaron Ballman authored
These functions were local to SemaDeclAttr.cpp, but these functions are useful in general (for instance, for statement or type attribute processing). This refactoring is in advance of beginning to tablegen diagnostic checks for statement attributes the way we already do for declaration attributes. There is one functional change in here as a drive-by. The external_source_symbol attribute had one of its diagnostic checks inside of an assert, which was corrected.
-
Philip Reames authored
LSR prefers to schedule iv increments just before the latch. The recent 80511565 broadened this to moving increments in the original IR. This pointed out a robustness problem with the CGP transform. When we have a use of an induction increment outside of the loop (we canonicalize away from this form, but it happens e.g. unanalyzeable loops) we'd avoid performing the uadd/usub transform. Interestingly, all of these involve moving the increment closer to it's operands, so there's no concern about dominating all uses. We can handle that case cheaply, resulting in a more robust transform.
-
Philip Reames authored
-
Mehdi Amini authored
This allows the caller to distinguish between a parse error or an unmatched keyword. It fixes the redundant error that was emitted by the caller when the generated parser would fail. Differential Revision: https://reviews.llvm.org/D98162
-
Mehdi Amini authored
Instead of storing an array of LoopOpt attributes, which were just wrapping std::pair<enum, int> anyway, we can have an attribute storing a sorted ArrayRef<std::pair<enum, int>> as a single unit. This improves here the textual format and the general API. Note that we're limiting the options to fit into an int64_t by design, but this isn't a new constraint. Building the LoopOptions attribute is likely worth a specific builder for efficient reason, that'll be the subject of a future patch. Differential Revision: https://reviews.llvm.org/D98105
-
Peter Collingbourne authored
There is no centralized store of information related to secondary allocations. Moreover the allocations themselves become inaccessible when the allocation is freed in order to implement UAF detection, so we can't store information there to be used in case of UAF anyway. Therefore our storage location for tracking stack traces of secondary allocations is a ring buffer. The ring buffer is copied to the process creating the crash dump when a fault occurs. The ring buffer is also used to store stack traces for primary deallocations. Stack traces for primary allocations continue to be stored inline. In order to support the scenario where an access to the ring buffer is interrupted by a concurrently occurring crash, the ring buffer is accessed in a lock-free manner. Differential Revision: https://reviews.llvm.org/D94212
-
Amara Emerson authored
For <2 x s32>, we can use G_DUPLANE32, but with a <4 x s32> source. To make it work, we can just widen the original source with a concat_vectors. Doing this allows <2 x float> indexed fmul instruction selection patterns to fire, which gives a nice 0.3% code size saving on Bullet with -Os. Differential Revision: https://reviews.llvm.org/D98059
-
Amara Emerson authored
If every element is extracted from a G_BUILD_VECTOR, pass through the source registers. This is different to the extract(build_vector) combine because this one tolerates multiple users as long as they're exhaustive. Differential Revision: https://reviews.llvm.org/D97890
-
Philip Reames authored
-
Amara Emerson authored
Differential Revision: https://reviews.llvm.org/D97835
-
Jay Foad authored
Refactor and add comments to explain where the magic numbers come from in terms of the instruction cache line size. NFC. Differential Revision: https://reviews.llvm.org/D98266
-
gbtozers authored
This patch implements DBG_VALUE_LIST handling to the LiveDebugValues pass. This is a substantial change, and makes a few fundamental changes to the existing logic. We still use the basic model of a VarLocMap that is indexed by a LocIndex, with a VarLocSet (a CoalescingBitVector underneath) giving us efficient lookups of existing variable locations for a given location type. The main change is that the VarLocMap may contain a given VarLoc multiple times (once for each unique location operand), so that a VarLoc can be looked up from any of the registers that it uses. This means that each VarLoc has multiple corresponding LocIndexes; to allow us to iterate through the set of VarLocs (previously we would iterate through the VarLocSet), we now also maintain a single entry in the VarLocMap that contains every VarLoc exactly once. The VarLoc class itself is also changed; this change is much simpler, refactoring out location-specific members into a MachineLocation class and adding a vector of these locations. Differential Revision: https://reviews.llvm.org/D83890
-
Jordan Rupprecht authored
After 5419b671 (which is `[SimplifyCFG] Update FoldTwoEntryPHINode to handle and/or of select and binop equally`), this uninitialized value is detected by msan.
-
Markus Böck authored
This test currently fails to compile when using a MinGW toolchain as setenv is not defined. This function is a POSIX function Windows does not implement. This patch enables the setenv macro used in the unit test for all of Windows, making the test compile and run successfully. Differential Revision: https://reviews.llvm.org/D98271
-
Fangrui Song authored
In -fno-exceptions -fno-asynchronous-unwind-tables -g0 mode, GCC does not emit `.cfi_*` directives. ``` % diff <(gcc -fno-asynchronous-unwind-tables -dM -E a.c) <(gcc -dM -E a.c) 130a131 > #define __GCC_HAVE_DWARF2_CFI_ASM 1 ``` This macro is useful because code can decide whether inline asm should include `.cfi_*` directives. `.cfi_*` directives without `.cfi_startproc` can cause assembler errors (integrated assembler: `this directive must appear between .cfi_startproc and .cfi_endproc directives`). Differential Revision: https://reviews.llvm.org/D97743
-
Jonas Devlieghere authored
Update the crashlog script for changes to the JSON schema. rdar://75122914 Differential revision: https://reviews.llvm.org/D98219
-
Jonas Devlieghere authored
This variable is used to reducing the likelihood of hitting module cache issues in CI where different branches can potentially run on the same machine.
-
Jonas Devlieghere authored
Use lit's with_system_environment function to propagate environment variables to the tests. Include the usual suspects, as well as the variables already explicitly forwarded.
-
Nikita Popov authored
llvm-jitlink and llvm-jitlink-executor make use of APIs that are part of the socket and nsl libraries on SunOS systems (Solaris and Illumos). Make sure they get linked. Ran into this in Rust CI when cross-compiling LLVM 12 to these targets. Differential Revision: https://reviews.llvm.org/D97633
-
Xiangling Liao authored
LLVM is recommending to use SmallVector (that is, omitting the N), in the absence of a well-motivated choice for the number of inlined elements N. However, this doesn't work well with XL compiler on AIX since some header(s) aren't properly picked up with it. We need to take a further look into the real issue underneath and fix it in a later patch. But currently we'd like to use this patch to unblock the build compiler issue first. Differential Revision: https://reviews.llvm.org/D98265
-
Craig Topper authored
I've left mask registers to a future patch as we'll need to convert them to full vectors, shuffle, and then truncate. Reviewed By: frasercrmck Differential Revision: https://reviews.llvm.org/D97609
-
Amara Emerson authored
-
Fangrui Song authored
GNU ld does not give SHF_GNU_RETAIN GC root semantics for ELFOSABI_NONE. (https://sourceware.org/pipermail/binutils/2021-March/115581.html) This allows GNU ld to interpret SHF_GNU_RETAIN and avoids a gold quirk https://sourceware.org/bugzilla/show_bug.cgi?id=27490 Because ELFObjectWriter is in an anonymous namespace, I have to place `markGnuAbi` in the parent MCObjectWriter. Differential Revision: https://reviews.llvm.org/D97976
-
Christudasan Devadasan authored
AMDGPU target tries to handle the SGPR and VGPR spills in a custom pass before the actual frame lowering pass. Once they are handled and the respective frames are eliminated in the custom pass, certain uses of them still remain. For instance, the DBG_VALUE instructions inserted by the allocator alongside the spill instruction will use the corresponding frame index. They become dead later during PEI and causes a crash while trying to replace the frame indices. We should possibly avoid this custom pass. For now, replacing such dead references with null register value. Reviewed By: arsenm, scott.linder Differential Revision: https://reviews.llvm.org/D98038
-
Nikita Popov authored
All extractvalues of the same value at the same index will map to the same register, so even if one specific extractvalue only has one use, we should not mark it as a trivial kill, as there may be more extractvalues later. Fixes https://bugs.llvm.org/show_bug.cgi?id=49467. Differential Revision: https://reviews.llvm.org/D98145
-