summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix a few warnings and style issues in MS demangler.Zachary Turner2018-07-201-17/+24
| | | | | | Also remove a broken test case. llvm-svn: 337591
* [X86] Remove isel patterns for MOVSS/MOVSD ISD opcodes with integer types.Craig Topper2018-07-204-79/+8
| | | | | | | | | | Ideally our ISD node types going into the isel table would have types consistent with their instruction domain. This prevents us having to duplicate patterns with different types for the same instruction. Unfortunately, it seems our shuffle combining is currently relying on this a little remove some bitcasts. This seems to enable some switching between shufps and shufd. Hopefully there's some way we can address this in the combining. Differential Revision: https://reviews.llvm.org/D49280 llvm-svn: 337590
* [X86] Remove what appear to be unnecessary uses of DCI.CombineToCraig Topper2018-07-201-19/+13
| | | | | | | | | | CombineTo is most useful when you need to replace multiple results, avoid the worklist management, or you need to something else after the combine, etc. Otherwise you should be able to just return the new node and let DAGCombiner go through its usual worklist code. All of the places changed in this patch look to be standard cases where we should be able to use the more stand behavior of just returning the new node. Differential Revision: https://reviews.llvm.org/D49569 llvm-svn: 337589
* Add a Microsoft Demangler.Zachary Turner2018-07-202-1/+1535
| | | | | | | | | | | | | This adds initial support for a demangling library (LLVMDemangle) and tool (llvm-undname) for demangling Microsoft names. This doesn't cover 100% of cases and there are some known limitations which I intend to address in followup patches, at least until such time that we have (near) 100% test coverage matching up with all of the test cases in clang/test/CodeGenCXX/mangle-ms-*. Differential Revision: https://reviews.llvm.org/D49552 llvm-svn: 337584
* [MemorySSA] Add API to update MemoryPhis, following CFG changes.Alina Sbirlea2018-07-201-0/+29
| | | | | | | | | | | | | | | | Summary: When splitting predecessors in BasicBlockUtils, we create a new block as an immediate predecessor of the original BB, then we connect a given set of predecessors to the new block. The API in this patch will be used to update MemoryPhis for this CFG change. If all predecessors are being moved, we move the MemoryPhi directly. Otherwise we create a new MemoryPhi in the NewBB and populate its incoming values, while deleting them from BB's Phi. [Split from D45299 for easier review] Reviewers: george.burgess.iv Subscribers: sanjoy, jlebar, Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D49156 llvm-svn: 337581
* [X86][XOP] Fix SUB constant folding for VPSHA/VPSHL shift loweringSimon Pilgrim2018-07-201-4/+3
| | | | | | | | We can safely use getConstant here as we're still lowering, which allows constant folding to kick in and simplify the vector shift codegen. Noticed while working on D49562. llvm-svn: 337578
* [MSan] Hotfix compilationAlexander Potapenko2018-07-201-0/+1
| | | | | | Make sure NewSI is used in materializeStores() llvm-svn: 337577
* [ARM] Add new feature to enable optimizing the VFP registersEvandro Menezes2018-07-203-2/+15
| | | | | | | | | Enable the optimization of operations on DPR and SPR via a feature instead of checking the target. Differential revision: https://reviews.llvm.org/D49463 llvm-svn: 337575
* [MSan] run materializeChecks() before materializeStores()Alexander Potapenko2018-07-201-7/+6
| | | | | | | | | | | | | | | | | | When pointer checking is enabled, it's important that every pointer is checked before its value is used. For stores MSan used to generate code that calculates shadow/origin addresses from a pointer before checking it. For userspace this isn't a problem, because the shadow calculation code is quite simple and compiler is able to move it after the check on -O2. But for KMSAN getShadowOriginPtr() creates a runtime call, so we want the check to be performed strictly before that call. Swapping materializeChecks() and materializeStores() resolves the issue: both functions insert code before the given IR location, so the new insertion order guarantees that the code calculating shadow address is between the address check and the memory access. llvm-svn: 337571
* [X86][SSE] Use SplitOpsAndApply to improve HADD/HSUB loweringSimon Pilgrim2018-07-201-8/+20
| | | | | | Improve AVX1 256-bit vector HADD/HSUB matching by using SplitOpsAndApply to split into 128-bit instructions. llvm-svn: 337568
* [X86][AVX] Add support for i16 256-bit vector horizontal op redundant ↵Simon Pilgrim2018-07-201-1/+3
| | | | | | shuffle removal llvm-svn: 337566
* Fix build breakage from r337562Pavel Labath2018-07-201-3/+3
| | | | | | | I changed a variable's type from pointer to reference, but forgot to update the assert-only code. llvm-svn: 337564
* [DAG] Avoid Node Update assertion due to AND simplificationNirav Dave2018-07-201-3/+5
| | | | | | | | | | | | | | | | | Check for construction-time folding for incomplete AND nodes in BackwardsPropagateMask. Fixes PR38185. Reviewers: RKSimon, samparker Reviewed By: samparker Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D49444 llvm-svn: 337563
* DwarfDebug: Reduce duplication in addAccel*** methodsPavel Labath2018-07-203-47/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Each of the four methods had a dozen lines and was doing almost exactly the same thing: get the appropriate accelerator table kind and insert an entry into it. I move this common logic to a helper function and make these methods delegate to it. This came up in the context of D49493, where I've needed to make adding a string to a string pool slightly more complicated, and it seemed to make sense to do it in one place instead of five. To make this work I've needed to unify the interface of the AccelTable data types, as some used to store DIE& and others DIE*. I chose to unify to a reference as that's what the caller uses. This technically isn't NFC, because it changes the StringPool used for apple tables in the DWO case (now it uses the main file like DWARF v5 instead of the DWO file). However, that shouldn't matter, as DWO is not a thing on apple targets (clang frontend simply ignores -gsplit-dwarf). Reviewers: JDevlieghere, aprantl, probinson Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49542 llvm-svn: 337562
* [X86][AVX] Add support for 32/64 bits 256-bit vector horizontal op redundant ↵Simon Pilgrim2018-07-201-5/+11
| | | | | | shuffle removal llvm-svn: 337561
* [DAG] Fix Memory ordering check in ReduceLoadOpStore.Nirav Dave2018-07-201-16/+18
| | | | | | | | | | | | | | | | | | When merging through a TokenFactor we need to check that the load may be ordered such that no other aliasing memory operations may happen. It is not sufficient to just check that the load is a member of the chain token factor as it there may be a indirect chain. Require the load's chain has only one use. This fixes PR37826. Reviewers: spatel, davide, efriedma, craig.topper, RKSimon Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D49388 llvm-svn: 337560
* [IPSCCP] Fix for bot failure caused by r337548Florian Hahn2018-07-201-1/+1
| | | | llvm-svn: 337554
* Recommit r328307: [IPSCCP] Use constant range information for comparisons of ↵Florian Hahn2018-07-201-110/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | parameters. This version contains a fix to add values for which the state in ParamState change to the worklist if the state in ValueState did not change. To avoid adding the same value multiple times, mergeInValue returns true, if it added the value to the worklist. The value is added to the worklist depending on its state in ValueState. Original message: For comparisons with parameters, we can use the ParamState lattice elements which also provide constant range information. This improves the code for PR33253 further and gets us closer to use ValueLatticeElement for all values. Also, as we are using the range information in the solver directly, we do not need tryToReplaceWithConstantRange afterwards anymore. Reviewers: dberlin, mssimpso, davide, efriedma Reviewed By: mssimpso Differential Revision: https://reviews.llvm.org/D43762 llvm-svn: 337548
* [X86][AVX] Convert X86ISD::VBROADCAST demanded elts combine to use ↵Simon Pilgrim2018-07-202-17/+48
| | | | | | | | | | SimplifyDemandedVectorElts This is an early step towards using SimplifyDemandedVectorElts for target shuffle combining - this merely moves the existing X86ISD::VBROADCAST simplification code to use the SimplifyDemandedVectorElts mechanism. Adds X86TargetLowering::SimplifyDemandedVectorEltsForTargetNode to handle X86ISD::VBROADCAST - in time we can support all target shuffles (and other ops) here. llvm-svn: 337547
* [InstSimplify] fold srem instruction if its two operands are negated.Chen Zheng2018-07-201-0/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D49423 llvm-svn: 337545
* [DebugInfo] Generate .debug_names section when it makes sensePavel Labath2018-07-203-17/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch makes us generate the debug_names section in response to some user-facing commands (previously it was only generated if explicitly selected via the -accel-tables option). My goal was to make this work for DWARF>=5 (as it's an official part of that standard), and also, as an extension, for DWARF<5 if one is explicitly tuning for lldb as a debugger (because it brings a large performance improvement there). This is slightly complicated by the fact that the debug_names tables are incompatible with the DWARF v4 type units (they assume that the type units are in the debug_info section), and unfortunately, right now we generate DWARF v4-style type units even for -gdwarf-5. For this reason, I disable all accelerator tables if the user requested type unit generation. I do this even for apple tables, as they have the same problem (in fact generating type units for apple targets makes us crash even before we get around to emitting the accelerator tables). Reviewers: JDevlieghere, aprantl, dblaikie, echristo, probinson Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49420 llvm-svn: 337544
* Revert "[LSV] Refactoring + supporting bitcasts to a type of different size"Sam McCall2018-07-201-62/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit r337489. It causes asserts to fire in some TensorFlow tests, e.g. tensorflow/compiler/tests/gather_test.py on GPU. Example stack trace: Start test case: GatherTest.testHigherRank assertion failed at third_party/llvm/llvm/lib/Support/APInt.cpp:819 in llvm::APInt llvm::APInt::trunc(unsigned int) const: width && "Can't truncate to 0 bits" @ 0x5559446ebe10 __assert_fail @ 0x55593ef32f5e llvm::APInt::trunc() @ 0x55593d78f86e (anonymous namespace)::Vectorizer::lookThroughComplexAddresses() @ 0x55593d78f2bc (anonymous namespace)::Vectorizer::areConsecutivePointers() @ 0x55593d78d128 (anonymous namespace)::Vectorizer::isConsecutiveAccess() @ 0x55593d78c926 (anonymous namespace)::Vectorizer::vectorizeInstructions() @ 0x55593d78c221 (anonymous namespace)::Vectorizer::vectorizeChains() @ 0x55593d78b948 (anonymous namespace)::Vectorizer::run() @ 0x55593d78b725 (anonymous namespace)::LoadStoreVectorizer::runOnFunction() @ 0x55593edf4b17 llvm::FPPassManager::runOnFunction() @ 0x55593edf4e55 llvm::FPPassManager::runOnModule() @ 0x55593edf563c (anonymous namespace)::MPPassManager::runOnModule() @ 0x55593edf5137 llvm::legacy::PassManagerImpl::run() @ 0x55593edf5b71 llvm::legacy::PassManager::run() @ 0x55593ced250d xla::gpu::IrDumpingPassManager::run() @ 0x55593ced5033 xla::gpu::(anonymous namespace)::EmitModuleToPTX() @ 0x55593ced40ba xla::gpu::(anonymous namespace)::CompileModuleToPtx() @ 0x55593ced33d0 xla::gpu::CompileToPtx() @ 0x55593b26b2a2 xla::gpu::NVPTXCompiler::RunBackend() @ 0x55593b21f973 xla::Service::BuildExecutable() @ 0x555938f44e64 xla::LocalService::CompileExecutable() @ 0x555938f30a85 xla::LocalClient::Compile() @ 0x555938de3c29 tensorflow::XlaCompilationCache::BuildExecutable() @ 0x555938de4e9e tensorflow::XlaCompilationCache::CompileImpl() @ 0x555938de3da5 tensorflow::XlaCompilationCache::Compile() @ 0x555938c5d962 tensorflow::XlaLocalLaunchBase::Compute() @ 0x555938c68151 tensorflow::XlaDevice::Compute() @ 0x55593f389e1f tensorflow::(anonymous namespace)::ExecutorState::Process() @ 0x55593f38a625 tensorflow::(anonymous namespace)::ExecutorState::ScheduleReady()::$_1::operator()() *** SIGABRT received by PID 7798 (TID 7837) from PID 7798; *** llvm-svn: 337541
* [SystemZ] Reimplent SchedModel IssueWidth and WriteRes/ReadAdvance mappings.Jonas Paulsson2018-07-205-2933/+3252
| | | | | | | | | | | | | | | | | As a consequence of recent discussions (http://lists.llvm.org/pipermail/llvm-dev/2018-May/123164.html), this patch changes the SystemZ SchedModels so that the IssueWidth is 6, which is the decoder capacity, and NumMicroOps become the number of decoder slots needed per instruction. In addition, the SchedWrite latencies now match the MachineInstructions def-operand indexes, and ReadAdvances have been added on instructions with one register operand and one memory operand. Review: Ulrich Weigand https://reviews.llvm.org/D47008 llvm-svn: 337538
* Improved sched model for X86 BSWAP* instrs.Andrew V. Tischenko2018-07-2011-79/+35
| | | | | | Differential Revision: https://reviews.llvm.org/D49477 llvm-svn: 337537
* Reapply "AMDGPU: Fix handling of alignment padding in DAG argument lowering"Matt Arsenault2018-07-2013-200/+219
| | | | | | Reverts r337079 with fix for msan error. llvm-svn: 337535
* [AArch64][SVE] Asm: Support for bit/byte reverse operations.Sander de Smalen2018-07-202-0/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the following instructions: RBIT reverse bits within each active elemnt (predicated), e.g. rbit z0.d, p0/m, z1.d for 8, 16, 32 and 64 bit elements. REV reverse order of elements in data/predicate vector (unpredicated), e.g. rev z0.d, z1.d rev p0.d, p1.d for 8, 16, 32 and 64 bit elements. REVB reverse order of bytes within each active element, e.g. revb z0.d, p0/m, z1.d for 16, 32 and 64 bit elements. REVH reverse order of 16-bit half-words within each active element, e.g. revh z0.d, p0/m, z1.d for 32 and 64 bit elements. REVW reverse order of 32-bit words within each active element, e.g. revw z0.d, p0/m, z1.d for 64 bit elements. llvm-svn: 337534
* [AArch64][SVE] Asm: Support for FTMAD instruction.Sander de Smalen2018-07-202-0/+27
| | | | | | | | | | | Floating-point trigonometric multiply-add coefficient, e.g. ftmad z0.h, z0.h, z1.h, #7 with variants for 16, 32 and 64-bit elements. llvm-svn: 337533
* [DAGCombiner] Fold X - (-Y *Z) -> X + (Y * Z)Craig Topper2018-07-201-0/+18
| | | | llvm-svn: 337518
* Reapply "ADT: Shrink size of SmallVector by 8B on 64-bit platforms"Duncan P. N. Exon Smith2018-07-201-11/+14
| | | | | | | | | | | | | | | | | | | | | | I'm optimistically reverting commit r337511, effectively reapplying r337504 *without* changes. The failing bots that had `SmallVector` in the backtrace recovered after the unrelated commit r337508. The backtraces looked bogus anyway, with `SmallVector::size()` calling (e.g.) `ConstantArray::get()`. Here's the original commit message: ADT: Shrink size of SmallVector by 8B on 64-bit platforms Represent size and capacity directly as unsigned and calculate `end()` using `begin() + size()`. This limits the maximum size/capacity of a vector to UINT32_MAX. https://reviews.llvm.org/D48518 llvm-svn: 337514
* [WebAssembly] Disable a test that violates DR1696Heejin Ahn2018-07-201-0/+1
| | | | | | | | | | | | | | Summary: lifetime2.C violates DR1696, which prevents reference members from being initialized to temporaries, whose lifetime would end at the end of ctor. Reviewers: sbc100 Subscribers: dschuff, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D49577 llvm-svn: 337512
* Revert "ADT: Shrink size of SmallVector by 8B on 64-bit platforms"Duncan P. N. Exon Smith2018-07-201-14/+11
| | | | | | | | | | | | | | | | | | This reverts commit r337504 while I investigate a TSan bot failure that seems related: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/26526 #8 0x000055581f2895d8 (/b/sanitizer-x86_64-linux-autoconf/build/tsan_debug_build/bin/clang-7+0x1eb45d8) #9 0x000055581f294323 llvm::ConstantAggrKeyType<llvm::ConstantArray>::create(llvm::ArrayType*) const /b/sanitizer-x86_64-linux-autoconf/build/llvm/lib/IR/ConstantsContext.h:409:0 #10 0x000055581f294323 llvm::ConstantUniqueMap<llvm::ConstantArray>::create(llvm::ArrayType*, llvm::ConstantAggrKeyType<llvm::ConstantArray>, std::pair<unsigned int, std::pair<llvm::ArrayType*, llvm::ConstantAggrKeyType<llvm::ConstantArray> > >&) /b/sanitizer-x86_64-linux-autoconf/build/llvm/lib/IR/ConstantsContext.h:635:0 #11 0x000055581f294323 llvm::ConstantUniqueMap<llvm::ConstantArray>::getOrCreate(llvm::ArrayType*, llvm::ConstantAggrKeyType<llvm::ConstantArray>) /b/sanitizer-x86_64-linux-autoconf/build/llvm/lib/IR/ConstantsContext.h:654:0 #12 0x000055581f2944cb llvm::ConstantArray::get(llvm::ArrayType*, llvm::ArrayRef<llvm::Constant*>) /b/sanitizer-x86_64-linux-autoconf/build/llvm/lib/IR/Constants.cpp:964:0 #13 0x000055581fa27e19 llvm::SmallVectorBase::size() const /b/sanitizer-x86_64-linux-autoconf/build/llvm/include/llvm/ADT/SmallVector.h:53:0 #14 0x000055581fa27e19 llvm::SmallVectorImpl<llvm::Constant*>::resize(unsigned long) /b/sanitizer-x86_64-linux-autoconf/build/llvm/include/llvm/ADT/SmallVector.h:347:0 #15 0x000055581fa27e19 (anonymous namespace)::EmitArrayConstant(clang::CodeGen::CodeGenModule&, clang::ConstantArrayType const*, llvm::Type*, unsigned int, llvm::SmallVectorImpl<llvm::Constant*>&, llvm::Constant*) /b/sanitizer-x86_64-linux-autoconf/build/llvm/tools/clang/lib/CodeGen/CGExprConstant.cpp:669:0 llvm-svn: 337511
* [x86/SLH] Clean up helper naming for return instruction handling andChandler Carruth2018-07-191-4/+26
| | | | | | | | | | | | | | remove dead declaration of a call instruction handling helper. This moves to the 'harden' terminology that I've been trying to settle on for returns. It also adds a really detailed comment explaining what all we're trying to accomplish with return instructions and why. Hopefully this makes it much more clear what exactly is being "hardened". Differential Revision: https://reviews.llvm.org/D49571 llvm-svn: 337510
* [SCCP] Don't use markForcedConstant on branch conditions.Eli Friedman2018-07-191-73/+62
| | | | | | | | | | | | It's more aggressive than we need to be, and leads to strange workarounds in other places like call return value inference. Instead, just directly mark an edge viable. Tests by Florian Hahn. Differential Revision: https://reviews.llvm.org/D49408 llvm-svn: 337507
* Skip out of SimplifyDemandedBits for BITCAST of f16 to i16Stephen Canon2018-07-191-0/+1
| | | | | | | | Mirrors the existing exit path for f128, avoiding a crash later on. Differential Revision: https://reviews.llvm.org/D49524 llvm-svn: 337506
* ADT: Shrink size of SmallVector by 8B on 64-bit platformsDuncan P. N. Exon Smith2018-07-191-11/+14
| | | | | | | | | | | Representing size and capacity directly as unsigned and calculate `end()` using `begin() + size()`. This limits the maximum size/capacity of a vector to UINT32_MAX. https://reviews.llvm.org/D48518 llvm-svn: 337504
* [ThinLTO] Only emit referenced type id records in index filesTeresa Johnson2018-07-191-5/+19
| | | | | | | | | | | | | | | | | | | | | | | Summary: Currently all type ids are emitted into the index file when it is written. For distributed ThinLTO, that meant that all type ids were being duplicated into every single distributed index file, regardless of whether they were referenced, leading to huge amounts of unnecessary duplication and size bloat. Keep track of the type id GUIDs actually referenced by the GV summary records being emitted, and only emit those type IDs. Add a new test, and fix test/Assembler/thinlto-summary.ll so that all type ids are referenced to prevent deletion in that test. Reviewers: pcc Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, vitalybuka, llvm-commits Differential Revision: https://reviews.llvm.org/D49565 llvm-svn: 337503
* [DAGCombiner] Teach DAGCombiner that A-(-B) is A+B.Craig Topper2018-07-191-0/+5
| | | | | | We already knew A+(-B) is A-B in visitAdd. This does the opposite for visitSub. llvm-svn: 337502
* [X86][AVX] Use extract_subvector to reduce vector op widths (PR36761)Simon Pilgrim2018-07-191-0/+25
| | | | | | | | | | We have a number of cases where we fail to reduce vector op widths, performing the op in a larger vector and then extracting a subvector. This is often because by default it would create illegal types. This peephole patch attempts to handle a few common cases detailed in PR36761, which typically involved extension+conversion to vX2f64 types. Differential Revision: https://reviews.llvm.org/D49556 llvm-svn: 337500
* [X86] Fix some 'return SDValue()' after DCI.CombineTo instead return the ↵Craig Topper2018-07-191-13/+7
| | | | | | | | | | output of CombineTo Returning SDValue() means nothing was changed. Returning the result of CombineTo returns the first argument of CombineTo. This is specially detected by DAGCombiner as meaning that something changed, but worklist management was already taken care of. I think the only real effect of this change is that we now properly update the Statistic the counts the number of combines performed. That's the only thing between the check for null and the check for N in the DAGCombiner. llvm-svn: 337491
* [LSV] Refactoring + supporting bitcasts to a type of different sizeRoman Tereshin2018-07-191-46/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is mostly a preparation work for adding a limited support for select instructions. It proved to be difficult to do due to size and irregularity of Vectorizer::isConsecutiveAccess, this is fixed here I believe. It also turned out that these changes make it simpler to finish one of the TODOs and fix a number of other small issues, namely: 1. Looking through bitcasts to a type of a different size (requires careful tracking of the original load/store size and some math converting sizes in bytes to expected differences in indices of GEPs). 2. Reusing partial analysis of pointers done by first attempt in proving them consecutive instead of starting from scratch. This added limited support for nested GEPs co-existing with difficult sext/zext instructions. This also required a careful handling of negative differences between constant parts of offsets. 3. Handing a case where the first pointer index is not an add, but something else (a function parameter for instance). I observe an increased number of successful vectorizations on a large set of shader programs. Only few shaders are affected, but those that are affected sport >5% less loads and stores than before the patch. Reviewed By: rampitec Differential-Revision: https://reviews.llvm.org/D49342 llvm-svn: 337489
* [Power9] Code Cleanup - Remove needsAggressiveScheduling()Stefan Pintilie2018-07-191-27/+8
| | | | | | | | | As we already return true from needsAggressiveScheduling() for the most recent hardware it would be cleaner to just return true for all PowerPC hardware. Differential Revision: https://reviews.llvm.org/D48663 llvm-svn: 337488
* [Analysis] Fix typo in assert. NFCShoaib Meenai2018-07-191-1/+1
| | | | | | Test commit to see if my mailing list woes have been resolved. llvm-svn: 337485
* [APInt] Keep the original bit width in quotient and remainderKrzysztof Parzyszek2018-07-191-16/+17
| | | | | | | | | | | Some trivial cases in udivrem were handled by directly assigning 0 or 1 to APInt objects. This would set the bit width to 1, instead of the bit width of the inputs. A potentially undesirable side effect of that is that with the bit width of 1, 1 equals -1. Differential Revision: https://reviews.llvm.org/D49554 llvm-svn: 337478
* [LoadStoreVectorizer] Use getMinusScev() to compute the distance between two ↵Farhana Aleen2018-07-191-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | pointers. Summary: Currently, isConsecutiveAccess() detects two pointers(PtrA and PtrB) as consecutive by comparing PtrB with BaseDelta+PtrA. This works when both pointers are factorized or both of them are not factorized. But isConsecutiveAccess() fails if one of the pointers is factorized but the other one is not. Here is an example: PtrA = 4 * (A + B) PtrB = 4 + 4A + 4B This patch uses getMinusSCEV() to compute the distance between two pointers. getMinusSCEV() allows combining the expressions and computing the simplified distance. Author: FarhanaAleen Reviewed By: rampitec Differential Revision: https://reviews.llvm.org/D49516 llvm-svn: 337471
* [X86][BtVer2] correctly model the latency/throughput of LEA instructions.Andrea Di Biagio2018-07-197-14/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes the latency/throughput of LEA instructions in the BtVer2 scheduling model. On Jaguar, A 3-operands LEA has a latency of 2cy, and a reciprocal throughput of 1. That is because it uses one cycle of SAGU followed by 1cy of ALU1. An LEA with a "Scale" operand is also slow, and it has the same latency profile as the 3-operands LEA. An LEA16r has a latency of 3cy, and a throughput of 0.5 (i.e. RThrouhgput of 2.0). This patch adds a new TIIPredicate named IsThreeOperandsLEAFn to X86Schedule.td. The tablegen backend (for instruction-info) expands that definition into this (file X86GenInstrInfo.inc): ``` static bool isThreeOperandsLEA(const MachineInstr &MI) { return ( ( MI.getOpcode() == X86::LEA32r || MI.getOpcode() == X86::LEA64r || MI.getOpcode() == X86::LEA64_32r || MI.getOpcode() == X86::LEA16r ) && MI.getOperand(1).isReg() && MI.getOperand(1).getReg() != 0 && MI.getOperand(3).isReg() && MI.getOperand(3).getReg() != 0 && ( ( MI.getOperand(4).isImm() && MI.getOperand(4).getImm() != 0 ) || (MI.getOperand(4).isGlobal()) ) ); } ``` A similar method is generated in the X86_MC namespace, and included into X86MCTargetDesc.cpp (the declaration lives in X86MCTargetDesc.h). Back to the BtVer2 scheduling model: A new scheduling predicate named JSlowLEAPredicate now checks if either the instruction is a three-operands LEA, or it is an LEA with a Scale value different than 1. A variant scheduling class uses that new predicate to correctly select the appropriate latency profile. Differential Revision: https://reviews.llvm.org/D49436 llvm-svn: 337469
* [ThinLTO] Enable ThinLTO WholeProgramDevirt and LowerTypeTests in new PMTeresa Johnson2018-07-195-29/+45
| | | | | | | | | | | | | | | | Summary: Enable these passes for CFI and WPD in ThinLTO and LTO with the new pass manager. Add a couple of tests for both PMs based on the clang tests tools/clang/test/CodeGen/thinlto-distributed-cfi*.ll, but just test through llvm-lto2 and not with distributed ThinLTO. Reviewers: pcc Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D49429 llvm-svn: 337461
* ARM: switch armv7em MachO triple to hard-float defaults and libcalls.Tim Northover2018-07-191-0/+2
| | | | | | | | | We were emitting incorrect calls to libm functions that LLVM had decided it knew about because the default is soft-float. Recommitted without breaking ELF this time. llvm-svn: 337450
* [x86/SLH] Major refactoring of SLH implementaiton. There are two bigChandler Carruth2018-07-191-174/+204
| | | | | | | | | | | | | | | | | | | | | | | | | | | | changes that are intertwined here: 1) Extracting the tracing of predicate state through the CFG to its own function. 2) Creating a struct to manage the predicate state used throughout the pass. Doing #1 necessitates and motivates the particular approach for #2 as now the predicate management is spread across different functions focused on different aspects of it. A number of simplifications then fell out as a direct consequence. I went with an Optional to make it more natural to construct the MachineSSAUpdater object. This is probably the single largest outstanding refactoring step I have. Things get a bit more surgical from here. My current goal, beyond generally making this maintainable long-term, is to implement several improvements to how we do interprocedural tracking of predicate state. But I don't want to do that until the predicate state management and tracing is in reasonably clear state. Differential Revision: https://reviews.llvm.org/D49427 llvm-svn: 337446
* Fix spelling mistake in comments. NFCI.Simon Pilgrim2018-07-191-2/+2
| | | | llvm-svn: 337442
* [SCEV] Fix buggy behavior in getAddExpr with truncsMax Kazantsev2018-07-191-1/+1
| | | | | | | | | | | | | | | | | SCEV tries to constant-fold arguments of trunc operands in SCEVAddExpr, and when it does that, it passes wrong flags into the recursion. It is only valid to pass flags that are proved for narrow type into a computation in wider type if we can prove that trunc instruction doesn't actually change the value. If it did lose some meaningful bits, we may end up proving wrong no-wrap flags for sum of arguments of trunc. In the provided test we end up with `nuw` where it shouldn't be because of this bug. The solution is to conservatively pass `SCEV::FlagAnyWrap` which is always a valid thing to do. Reviewed By: sanjoy Differential Revision: https://reviews.llvm.org/D49471 llvm-svn: 337435
OpenPOWER on IntegriCloud