summaryrefslogtreecommitdiffstats
path: root/llvm/test
Commit message (Collapse)AuthorAgeFilesLines
* Try to fix Windows bot by forcing "rm".Tim Northover2018-03-093-10/+10
| | | | llvm-svn: 327139
* [dsymutil] Unify error handling and add colorJonas Devlieghere2018-03-092-2/+2
| | | | | | | | | We improved the handling of errors and warnings in dwarfdump's verifier in rL314498. This patch does the same thing for dsymutil. Differential revision: https://reviews.llvm.org/D44052 llvm-svn: 327137
* [x86][aarch64] ask the backend whether it has a vector blend instructionSebastian Pop2018-03-092-2/+12
| | | | | | | | | | | | | The code to match and produce more x86 vector blends was enabled for all architectures even though the transform may pessimize the code for other architectures that do not provide a vector blend instruction. Added an aarch64 testcase to check that a VZIP instruction is generated instead of byte movs. Differential Revision: https://reviews.llvm.org/D44118 llvm-svn: 327132
* TableGen: Add a defset statementNicolai Haehnle2018-03-092-0/+76
| | | | | | | | | | | | | | | | | | | | | | | | Allows capturing a list of concrete instantiated defs. This can be combined with foreach to create parallel sets of def instantiations with less repetition in the source. This purpose is largely also served by multiclasses, but in some cases multiclasses can't be used. The motivating example for this change is having a large set of intrinsics, which are generated from the IntrinsicsBackend.td file included by Intrinsics.td, and a corresponding set of instruction selection patterns, which are generated via the backend's .td files. Multiclasses cannot be used to eliminate the redundancy in this case, because a multiclass cannot span both LLVM's common .td files and the backend .td files at the same time. Change-Id: I879e35042dceea542a5e6776fad23c5e0e69e76b Differential revision: https://reviews.llvm.org/D44109 llvm-svn: 327121
* TableGen: Allow arbitrary list values as ranges of foreachNicolai Haehnle2018-03-091-0/+19
| | | | | | | | | The changes to FieldInit are required to make field references (Def.field) work inside a ForeachDeclaration: previously, Def.field wasn't resolved immediately when Def was already a fully resolved DefInit. Change-Id: I9875baec2fc5aac8c2b249e45b9cf18c65ae699b llvm-svn: 327120
* TableGen: add !isa operationNicolai Haehnle2018-03-091-0/+39
| | | | | | | | Change-Id: Iddb724c3ae706d82933a2d82c91d07e0e36b30e3 Differential revision: https://reviews.llvm.org/D44105 llvm-svn: 327117
* [DebugInfo/AccelTable] Fix inconsistency in getDIEOffset implementationsPavel Labath2018-03-093-5/+155
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Even though the getDIEOffset offset function was common for the two accelerator table implementations, it was doing two different things: for the Apple tables, it was returning the die offset relative to the start of the section, whereas for DWARF v5 tables, it was relative to the start of the CU. I resolve this by renaming the function to getDIESectionOffset to make it obvious what the function returns, and change the DWARF implementation to return the section offset. I also keep the CU-relative accessor, but only in the DWARF implementation (there is no way to get this information for the Apple tables). This was not caught by existing tests because the hand-written inputs also erroneously used section offsets instead of CU-relative ones. While looking at this, I noticed that the Apple implementation was not fully correct either -- the header contains a DIEOffsetBase field, which should be added to offsets encoded with the DW_FORM_ref*** family, but this was not being used. This went unnoticed because all current writers set this field to zero anyway. I fix this as well and add a hand-written test which demonstrates the issue. Reviewers: JDevlieghere, dblaikie Subscribers: aprantl, llvm-commits Differential Revision: https://reviews.llvm.org/D44202 llvm-svn: 327116
* [AArch64] Fix use of a regex in the win-alloca.ll test. NFC.Martin Storsjo2018-03-091-1/+1
| | | | | | | Check that the variable actually is the same as the one previously matched. llvm-svn: 327107
* [AMDGPU] Fixed V_DIV_FIXUP_F16 selection on GFX9Stanislav Mekhanoshin2018-03-091-58/+59
| | | | | | | | GFX9 should select opsel version. Differential Revision: https://reviews.llvm.org/D44279 llvm-svn: 327106
* Don't treat .symver as a regular alias definition.Rafael Espindola2018-03-091-3/+3
| | | | | | | | | | | | | | This patch starts simplifying the handling of .symver. For now it just moves the responsibility for creating an alias down to the streamer. With that the asm streamer can pass a .symver unchanged, which is nice since gas cannot parse "foo@bar = zed". In a followup I hope to move the handling down to the writer so that we don't need special hacks for avoiding breaking names with @@@ on windows. llvm-svn: 327101
* Attempt to fix vecreduce-propagate-sd-flags.ll test.Matt Morehouse2018-03-091-1/+1
| | | | | | Buildbots have been failing since r327079. llvm-svn: 327100
* Revert "[ThinLTO] Keep available_externally symbols live"Eric Christopher2018-03-093-34/+0
| | | | | | This reverts commit r327041 and the followup attempts at fixing the testcase as they're still failing. llvm-svn: 327094
* [X86] Remove SRAs from v16i8 multiply lowering on sse2 targetsCraig Topper2018-03-093-85/+39
| | | | | | | | | | Previously we unpacked the even bytes of each input into the high byte of 16-bit elements then did an v8i16 arithmetic shift right by 8 bits to fill the upper bits of each word with sign bits. Then we did the v8i16 multiply and then masked to zero the upper 8-bits of each result. The similar was done for all the odd bytes. The results are then packed together with packuswb Since we are masking each multiply result element to 8-bits, and those 8-bits are determined only by the lower 8-bits of each of the inputs, we don't need to fill the upper bits with sign bits. So we can just unpack into the low byte of each element and treat the upper bits as garbage. This is what gcc also does. Differential Revision: https://reviews.llvm.org/D44267 llvm-svn: 327093
* LowerDbgDeclare: ignore dbg.declares for allocas with volatile accessAdrian Prantl2018-03-092-3/+88
| | | | | | | | | | | There is no point in lowering a dbg.declare describing an alloca that has volatile loads or stores as users, since the alloca cannot be elided. Lowering the dbg.declare will result in larger debug info that may also have worse coverage than just describing the alloca. rdar://problem/34496278 llvm-svn: 327092
* Revert "[DWARF] Fix mixing assembler -g with DWARF .file directives."Paul Robinson2018-03-091-1/+1
| | | | | | | This reverts commit d6d9ac1ab5039ba1fe0f63c36eac2bdd9f0a79c9. aka r327073 llvm-svn: 327083
* Propagate flags to SDValue in SplitVecOp_VECREDUCESameer AbuAsal2018-03-081-0/+31
| | | | | | | | | | | | This patch is a fix for PR36642. While legalizing long vector types, make sure the smaller types get the flags of the wider type. bugzilla link: https://bugs.llvm.org/show_bug.cgi?id=36642 Change-Id: I0c2829639f094c862c10a6b51b342d4c2563e1fa llvm-svn: 327079
* [DWARF] Fix mixing assembler -g with DWARF .file directives.Paul Robinson2018-03-081-1/+1
| | | | | | | | | | | We were effectively overriding an explicit '.file' directive with info for the assembler source. That shouldn't happen. Fixes PR36636. Differential Revision: https://reviews.llvm.org/D44265 llvm-svn: 327073
* [DebugInfo] Add DW_AT_byte_size to vectorsMatt Davis2018-03-081-0/+47
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds the DW_AT_byte_size dwarf attribute to vectors. This fixes PR21924 LLVM will round a vector up to the next alignable address, which can result in the vector's representation in the object file being larger than what the debugger will calculate via NumberOfElements * ElementSize. In such a case calling sizeof(MyVec) in the source will result in a different value than what a debugger might present. This situation can occur because LLVM permits non-power of two 'vector_size' attributes. Reviewers: echristo, dexonsmith, aprantl Reviewed By: aprantl Subscribers: probinson, aprantl, llvm-commits, JDevlieghere Tags: #debug-info Differential Revision: https://reviews.llvm.org/D44048 llvm-svn: 327072
* [Reassociate] fix test to be independent of FP undefSanjay Patel2018-03-081-14/+17
| | | | llvm-svn: 327071
* [AMDGPU] fix test to survive more FP undef constant foldingSanjay Patel2018-03-081-5/+6
| | | | llvm-svn: 327066
* [asan] Fix a false positive ODR violation due to LTO ConstantMerge pass ↵Kuba Mracek2018-03-081-0/+30
| | | | | | | | | | [llvm part, take 3] This fixes a false positive ODR violation that is reported by ASan when using LTO. In cases, where two constant globals have the same value, LTO will merge them, which breaks ASan's ODR detection. Differential Revision: https://reviews.llvm.org/D43959 llvm-svn: 327061
* [DWARF v5] Support for verbose dumping of .debug_rnglist entriesWolfgang Pieb2018-03-083-38/+84
| | | | | | | | | | | | | | | | Adding verbose dumping to the recent implementation of dumping of v5 range list entries. We're capturing the entries as is as they come in during extraction, including their file offset, so we can dump them in more detail. The offset table entries which are table-relative are shown as is (as in non-verbose mode) and with the actual file offset they map to. Reviewers: dblaikie, aprantl, jdevlieghere, jhenderson Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43366 llvm-svn: 327059
* [ConstantFold] fp_binop undef, undef --> undefSanjay Patel2018-03-084-13/+15
| | | | | | | | | | | | | | | | | These are uncontroversial and independent of a proposed LangRef edits (D44216). I tried to fix tests that would fold away: rL327004 rL327028 rL327030 rL327034 I'm not sure if the Reassociate tests are meaningless yet, but they probably will be as we add more folds, so if anyone has suggestions or wants to fix those, please do. Differential Revision: https://reviews.llvm.org/D44258 llvm-svn: 327058
* [llvm-mca] Fix handling of zero-latency instructions.Andrea Di Biagio2018-03-083-0/+100
| | | | | | | | | | | | | | | | | | | | This patch fixes a problem found when testing zero latency instructions on target AArch64 -mcpu=exynos-m3 / -mcpu=exynos-m1. On Exynos-m3/m1, direct branches are zero-latency instructions that don't consume any processor resources. The DispatchUnit marks zero-latency instructions as "executed", so that no scheduling is required. The event of instruction executed is then notified to all the listeners, and the reorder buffer (managed by the RetireControlUnit) is updated. In particular, the entry associated to the zero-latency instruction in the reorder buffer is marked as executed. Before this patch, the DispatchUnit forgot to assign a retire control unit token (RCUToken) to the zero-latency instruction. As a consequence, the RCUToken was used uninitialized. This was causing a crash in the RetireControlUnit logic. Fixes PR36650. llvm-svn: 327056
* Revert r327053.Kuba Mracek2018-03-081-30/+0
| | | | llvm-svn: 327055
* [asan] Fix a false positive ODR violation due to LTO ConstantMerge pass ↵Kuba Mracek2018-03-081-0/+30
| | | | | | | | | | [llvm part, take 2] This fixes a false positive ODR violation that is reported by ASan when using LTO. In cases, where two constant globals have the same value, LTO will merge them, which breaks ASan's ODR detection. Differential Revision: https://reviews.llvm.org/D43959 llvm-svn: 327053
* Specify that test from r327041 requires assertsVlad Tsyrklevich2018-03-081-0/+1
| | | | llvm-svn: 327051
* [DebugInfo] Add verifier for DICompositeType vectorMatt Davis2018-03-081-0/+36
| | | | | | | | | | | | | | | | | | | Summary: This patch adds verification logic for DICompositeType vectors, ensuring that they only have one element, and that element is of type subrange. This patch complements https://reviews.llvm.org/D44048 Reviewers: aprantl Reviewed By: aprantl Subscribers: JDevlieghere, llvm-commits Tags: #debug-info Differential Revision: https://reviews.llvm.org/D44262 llvm-svn: 327048
* Fix test failure introduced in r327041Vlad Tsyrklevich2018-03-081-1/+1
| | | | | | | The "Assertion: `...' failed" error message format is not identical across platforms. llvm-svn: 327047
* [ThinLTO] Keep available_externally symbols liveVlad Tsyrklevich2018-03-083-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change fixes PR36483. The bug was originally introduced by a change that marked non-prevailing symbols dead. This broke LowerTypeTests handling of available_externally functions, which are non-prevailing. LowerTypeTests uses liveness information to avoid emitting thunks for unused functions. Marking available_externally functions dead is incorrect, the functions are used though the function definitions are not. This change keeps them live, and lets the EliminateAvailableExternally/GlobalDCE passes remove them later instead. I've also enabled EliminateAvailableExternally for all optimization levels, I believe it being disabled for O1 was an oversight. Reviewers: pcc, tejohnson Reviewed By: tejohnson Subscribers: grimar, mehdi_amini, inglorion, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D43690 llvm-svn: 327041
* [InstCombine] add min/max tests with not ops; NFCSanjay Patel2018-03-081-44/+108
| | | | | | | | | | These are based on: https://bugs.llvm.org/show_bug.cgi?id=35875 It's not clear if/how instcombine can reduce these, but we should have the tests here either way to document current behavior. llvm-svn: 327039
* [Hexagon] Ignore indexed loads when handling unaligned loadsKrzysztof Parzyszek2018-03-081-0/+67
| | | | llvm-svn: 327037
* [Tests] Remove empty test file that causes the test suite to failDavid Zarzycki2018-03-081-0/+0
| | | | | | | This empty file was "created" by r327033, which attempted to revert r327029, which introduced the file. llvm-svn: 327036
* [AMDGPU] fix test to survive the most basic undef constant foldingSanjay Patel2018-03-081-1/+1
| | | | | | | This will likely need to be changed again for anything more than: fmul undef, undef -> undef llvm-svn: 327034
* Revert r327029Kuba Mracek2018-03-081-30/+0
| | | | llvm-svn: 327033
* [x86] fix test to be independent of FP undef Sanjay Patel2018-03-081-10/+11
| | | | llvm-svn: 327030
* [asan] Fix a false positive ODR violation due to LTO ConstantMerge pass ↵Kuba Mracek2018-03-081-0/+30
| | | | | | | | | | [llvm part] This fixes a false positive ODR violation that is reported by ASan when using LTO. In cases, where two constant globals have the same value, LTO will merge them, which breaks ASan's ODR detection. Differential Revision: https://reviews.llvm.org/D43959 llvm-svn: 327029
* [StructurizeCFG] fix test to be independent of FP undefSanjay Patel2018-03-081-5/+7
| | | | llvm-svn: 327028
* [x86] regenerate checks; NFCSanjay Patel2018-03-081-4/+20
| | | | | | This test will fail if we fix FP undef constant folding. llvm-svn: 327026
* [StructurizeCFG] auto-generate full checks; NFCSanjay Patel2018-03-081-3/+22
| | | | | | Not sure what the intent of this test is, but this will change when we fix FP undef constant folding. llvm-svn: 327022
* [InstCombine] regenerate checks; NFCSanjay Patel2018-03-081-23/+33
| | | | | | | We may not need any of these tests after rL327012, but leaving them here for now until that's confirmed. llvm-svn: 327014
* [InstSimplify] add more tests for FP undef; NFCSanjay Patel2018-03-081-0/+376
| | | | llvm-svn: 327012
* DWARFVerifier: Basic verification of .debug_namesPavel Labath2018-03-087-0/+458
| | | | | | | | | | | | | | | | | Summary: This patch adds basic .debug_names verification capabilities to the DWARF verifier. Right now, it checks that the headers and abbreviation tables of the individual name indexes can be parsed correctly, it verifies the buckets table and the cross-checks the CU lists for consistency. I intend to add further checks in follow-up patches. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: vleschuk, echristo, clayborg, llvm-commits Differential Revision: https://reviews.llvm.org/D44211 llvm-svn: 327011
* [llvm-mca] Emit the 'Instruction Info' table before the resource pressure view.Andrea Di Biagio2018-03-085-72/+78
| | | | | | | In future, both the summary information and the 'instruction info' table should be moved into a separate "Summary" view. llvm-svn: 327010
* [InstCombine, NewGVN] remove FP undef from testsSanjay Patel2018-03-082-3/+3
| | | | | | | | I'm trying to preserve the intent of these tests by using non-undef operands; if we fix FP undef folding these tests will not pass. llvm-svn: 327004
* [CMake] Add missing test dependencyDavid Zarzycki2018-03-082-1/+2
| | | | | | This makes 'ninja clean ; ninja check-all' work again. llvm-svn: 327002
* [llvm-mca] LLVM Machine Code Analyzer.Andrea Di Biagio2018-03-0817-0/+431
| | | | | | | | | | | | | | | | | | | | | | | | | | | llvm-mca is an LLVM based performance analysis tool that can be used to statically measure the performance of code, and to help triage potential problems with target scheduling models. llvm-mca uses information which is already available in LLVM (e.g. scheduling models) to statically measure the performance of machine code in a specific cpu. Performance is measured in terms of throughput as well as processor resource consumption. The tool currently works for processors with an out-of-order backend, for which there is a scheduling model available in LLVM. The main goal of this tool is not just to predict the performance of the code when run on the target, but also help with diagnosing potential performance issues. Given an assembly code sequence, llvm-mca estimates the IPC (instructions per cycle), as well as hardware resources pressure. The analysis and reporting style were mostly inspired by the IACA tool from Intel. This patch is related to the RFC on llvm-dev visible at this link: http://lists.llvm.org/pipermail/llvm-dev/2018-March/121490.html Differential Revision: https://reviews.llvm.org/D43951 llvm-svn: 326998
* [dsymutil] Embed toolchain in dSYM bundleJonas Devlieghere2018-03-082-1/+7
| | | | | | | | | Allow us to embed the (Xcode) toolchain in the dSYM bundle's property list. Differential revision: https://reviews.llvm.org/D44151 llvm-svn: 326994
* [X86] Change X86::PMULDQ/PMULUDQ opcodes to take vXi64 type as input instead ↵Craig Topper2018-03-085-124/+115
| | | | | | | | | | | | of vXi32. This instruction can be thought of as reading either the even elements of a vXi32 input or the lower half of each element of a vXi64 input. We currently use the vXi32 interpretation, but vXi64 matches better with its broadcast behavior in EVEX. I'm looking at moving MULDQ/MULUDQ creation to a DAG combine so we can do it when AVX512DQ is enabled without having to go through Custom lowering. But in some of the test cases we failed to use a broadcast load due to the size difference. This should help with that. I'm also wondering if we can model these instructions in native IR and remove the intrinsics and I think using a vXi64 type will work better with that. llvm-svn: 326991
* Revert "[LTO] Support filtering by hotness threshold"Bob Haarman2018-03-082-39/+3
| | | | | | | | This reverts commit 1f3bd185c53beb6aa68446974b7e80837abd6ef0 (r326107) because it fails ThinLTO/X86/diagnostic-handler-remarks-with-hotness.ll. llvm-svn: 326975
OpenPOWER on IntegriCloud