summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* [DAGCombiner] don't hoist logic op if operands have other usesSanjay Patel2018-12-061-2/+6
| | | | | | | | | | | | | | | | | The AVX512 diffs are neutral, but the bswap test shows a clear overreach in hoistLogicOpWithSameOpcodeHands(). If we don't check for other uses, we can increase the instruction count. This could also fight with transforms trying to go in the opposite direction and possibly blow up/infinite loop. This might be enough to solve the bug noted here: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20181203/608593.html I did not add the hasOneUse() checks to all opcodes because I see a perf regression for at least one opcode. We may decide that's irrelevant in the face of potential compiler crashing, but I'll see if I can salvage that first. llvm-svn: 348508
* [PDB] Move some code around. NFC.Zachary Turner2018-12-062-1/+55
| | | | llvm-svn: 348505
* [DAGCombiner] refactor function that hoists bitwise logic; NFCISanjay Patel2018-12-061-56/+65
| | | | | | | | | Added FIXME and TODO comments for lack of safety checks. This function is a suspect in out-of-memory errors as discussed in the follow-up thread to r347917: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20181203/608593.html llvm-svn: 348501
* Support skewed stream arrays.Zachary Turner2018-12-062-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VarStreamArray was built on the assumption that it is backed by a StreamRef, and offset 0 of that StreamRef is the first byte of the first record in the array. This is a logical and intuitive assumption, but unfortunately we have use cases where it doesn't hold. Specifically, a PDB module's symbol stream is prefixed by 4 bytes containing a magic value, and the first byte of record data in the array is actually at offset 4 of this byte sequence. Previously, we would just truncate the first 4 bytes and then construct the VarStreamArray with the resulting StreamRef, so that offset 0 of the underlying stream did correspond to the first byte of the first record, but this is problematic, because symbol records reference other symbol records by the absolute offset including that initial magic 4 bytes. So if another record wants to refer to the first record in the array, it would say "the record at offset 4". This led to extremely confusing hacks and semantics in loading code, and after spending 30 minutes trying to get some math right and failing, I decided to fix this in the underlying implementation of VarStreamArray. Now, we can say that a stream is skewed by a particular amount. This way, when we access a record by absolute offset, we can use the same values that the records themselves contain, instead of having to do fixups. Differential Revision: https://reviews.llvm.org/D55344 llvm-svn: 348499
* [X86] Refactored IsSplatVector to use switch. NFCI.Simon Pilgrim2018-12-061-21/+24
| | | | | | | | Initial step towards making the function more generic (and probably move into SelectionDAG). This is necessary to avoid massive codegen bloat for PR38243 (Add modulo rotate support to LowerRotate). llvm-svn: 348498
* [DEBUGINFO, NVPTX] Disable emission of ',debug' option if only debug ↵Alexey Bataev2018-12-061-1/+15
| | | | | | | | | | | | | | | | | directives are allowed. Summary: If the output of debug directives only is requested, we should drop emission of ',debug' option from the target directive. Required for supporting of nvprof profiler. Reviewers: echristo Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D46061 llvm-svn: 348497
* [GVN] Don't perform scalar PRE on GEPsAlexandros Lamprineas2018-12-061-0/+10
| | | | | | | | | | | | | | | Partial Redundancy Elimination of GEPs prevents CodeGenPrepare from sinking the addressing mode computation of memory instructions back to its uses. The problem comes from the insertion of PHIs, which confuse CGP and make it bail. I've autogenerated the check lines of an existing test and added a store instruction to demonstrate the motivation behind this change. The store is now using the gep instead of a phi. Differential Revision: https://reviews.llvm.org/D55009 llvm-svn: 348496
* [DEBUGINFO, NVPTX]Emit last debugging directives.Alexey Bataev2018-12-063-3/+15
| | | | | | | | | | | | | | | Summary: We may end up with not emitted debug directives at the end of the module emission. Patch fixes this problem emitting those last directives the end of the module emission. Reviewers: echristo Subscribers: jholewinski, llvm-commits Differential Revision: https://reviews.llvm.org/D54320 llvm-svn: 348495
* DAGCombiner::visitINSERT_VECTOR_ELT - pull out repeated ↵Simon Pilgrim2018-12-061-3/+4
| | | | | | VT.getVectorNumElements(). NFCI. llvm-svn: 348494
* [NFC][AArch64] Split out backend featuresDiogo N. Sampaio2018-12-066-72/+297
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch splits backend features currently hidden behind architecture versions. For example, currently the only way to activate complex numbers extension is targeting an v8.3 architecture, where after the patch this extension can be added separately. This refactoring is required by the new command lines proposal: http://lists.llvm.org/pipermail/llvm-dev/2018-September/126346.html Reviewers: DavidSpickett, olista01, t.p.northover Subscribers: kristof.beyls, bryanpkc, javed.absar, pbarrio Differential revision: https://reviews.llvm.org/D54633 -- It was reverted in rL348249 due a build bot failure in one of the regression tests: http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/14386 The problem seems to be that FileCheck behaves different in windows and linux. This new patch splits the test file in multiple, and does more exact pattern matching attempting to circumvent the issue. llvm-svn: 348493
* AMDGPU: Generate VALU ThreeOp Integer instructionsNicolai Haehnle2018-12-061-0/+47
| | | | | | | | | | | | | | | Summary: Original patch by: Fabian Wahlster <razor@singul4rity.com> Change-Id: I148f692a88432541fad468963f58da9ddf79fac5 Reviewers: arsenm, rampitec Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, b-sumner, llvm-commits Differential Revision: https://reviews.llvm.org/D51995 llvm-svn: 348488
* [AMDGPU] Partial revert of rL348371: Turn on the DPP combiner by defaultValery Pykhtin2018-12-061-1/+1
| | | | | | | | Turn the combiner back off as there're failures until the issue is fixed. Differential revision: https://reviews.llvm.org/D55314 llvm-svn: 348487
* Revert "[LoopSimplifyCFG] Delete dead in-loop blocks"Ilya Biryukov2018-12-061-32/+10
| | | | | | | | This reverts commit r348457. The original commit causes clang to crash when doing an instrumented build with a new pass manager. Reverting to unbreak our integrate. llvm-svn: 348484
* Test commit: Removed trailing space in .txt file.Markus Lavin2018-12-061-2/+2
| | | | llvm-svn: 348483
* [ARM GlobalISel] Nothing is legal for ThumbDiana Picus2018-12-061-0/+7
| | | | | | | | | | | | | | ...yet! A lot of the current code should be shared for arm and thumb mode, but until we add tests and work out some of the details (e.g. checking the correct subtarget feature for G_SDIV) it's safer to bail out as early as possible for thumb targets. This should have arguably been part of r348347, which allowed Thumb functions to be handled by the IR Translator. llvm-svn: 348472
* [InstCombine] foldICmpWithLowBitMaskedVal(): don't miscompile -1 vector eltsRoman Lebedev2018-12-061-0/+4
| | | | | | | | | | | | | | | | I was finally able to quantify what i thought was missing in the fix, it was vector constants. If we have a scalar (and %x, -1), it will be instsimplified before we reach this code, but if it is a vector, we may still have a -1 element. Thus, we want to avoid the fold if *at least one* element is -1. Or in other words, ignoring the undef elements, no sign bits should be set. Thus, m_NonNegative(). A follow-up for rL348181 https://bugs.llvm.org/show_bug.cgi?id=39861 llvm-svn: 348462
* [X86] Remove some leftover code for handling an i1 setcc type. NFCCraig Topper2018-12-061-5/+2
| | | | | | We should only need to handle i8 now. llvm-svn: 348460
* [LoopSimplifyCFG] Delete dead in-loop blocksMax Kazantsev2018-12-061-10/+32
| | | | | | | | | | This patch teaches LoopSimplifyCFG to delete loop blocks that have become unreachable after terminator folding has been done. Differential Revision: https://reviews.llvm.org/D54023 Reviewed By: anna llvm-svn: 348457
* AArch64: Fix invalid CCMP emissionMatthias Braun2018-12-061-93/+124
| | | | | | | | | | | | | | | | | | The code emitting AND-subtrees used to check whether any of the operands was an OR in order to figure out if the result needs to be negated. However the OR could be hidden in further subtrees and not immediately visible. Change the code so that canEmitConjunction() determines whether the result of the generated subtree needs to be negated. Cleanup emission logic to use this. I also changed the code a bit to make all negation decisions early before we actually emit the subtrees. This fixes http://llvm.org/PR39550 Differential Revision: https://reviews.llvm.org/D54137 llvm-svn: 348444
* Add objc.* ARC intrinsics and codegen them to their runtime methods.Pete Cooper2018-12-061-0/+36
| | | | | | | | Reviewers: erik.pilkington, ahatanak Differential Revision: https://reviews.llvm.org/D55233 llvm-svn: 348441
* [MachineOutliner][NFC] Move yet another std::vector out of a loopJessica Paquette2018-12-061-3/+4
| | | | | | | | Once again, following the wisdom of the LLVM Programmer's Manual. I think that's enough refactoring for today. :) llvm-svn: 348439
* [MachineOutliner][NFC] Move std::vector out of loopJessica Paquette2018-12-061-1/+2
| | | | | | See http://llvm.org/docs/ProgrammersManual.html#vector llvm-svn: 348433
* [MachineOutliner][NFC] Remove IntegerInstructionMap from InstructionMapperJessica Paquette2018-12-061-9/+2
| | | | | | | | | | Refactoring. This map was only used when we used a string of integers to output the outlined sequence. Since it's no longer used for anything, there's no reason to keep it around. llvm-svn: 348432
* [GlobalISel] Introduce G_BUILD_VECTOR, G_BUILD_VECTOR_TRUNC and ↵Amara Emerson2018-12-052-0/+115
| | | | | | | | | | | | | | | | | | | | | | | G_CONCAT_VECTOR opcodes. These opcodes are intended to subsume some of the capability of G_MERGE_VALUES, as it was too powerful and thus complex to add deal with throughout the GISel pipeline. G_BUILD_VECTOR creates a vector value from a sequence of uniformly typed scalar values. G_BUILD_VECTOR_TRUNC is a special opcode for handling scalar operands which are larger than the destination vector element type, and therefore does an implicit truncate. G_CONCAT_VECTOR creates a vector by concatenating smaller, uniformly typed, vectors together. These will be used in a subsequent commit. This commit just adds the initial infrastructure. Differential Revision: https://reviews.llvm.org/D53594 llvm-svn: 348430
* [MachineOutliner][NFC] Remove buildCandidateList and replace with findCandidatesJessica Paquette2018-12-051-45/+9
| | | | | | | | | | | | | | More refactoring. Since the pruning logic has changed, and the candidate list is gone, everything can be sunk into findCandidates. We no longer need to keep track of the length of the longest substring, so we can drop all of that logic as well. After this, we just find all of the candidates and move to outlining. llvm-svn: 348428
* [MachineOutliner][NFC] Candidates don't need to be shared_ptrs anymoreJessica Paquette2018-12-051-11/+10
| | | | | | | | | | | More refactoring. After the changes to the pruning logic, and removing CandidateList, there's no reason for Candiates to be shared_ptrs (or pointers at all). std::shared_ptr<Candidate> -> Candidate. llvm-svn: 348427
* Revert r347934 "[SCEV] Guard movement of insertion point for loop-invariants"David L. Jones2018-12-051-42/+41
| | | | | | | | This change caused SEGVs in instcombine. (The r347934 change seems to me to be a precipitating cause, not a root cause. Details are on the llvm-commits thread for r347934.) llvm-svn: 348426
* [InstCombine] remove dead code from visitExtractElementSanjay Patel2018-12-051-6/+0
| | | | | | | | Extracting from a splat constant is always handled by InstSimplify. Move the test for this from InstCombine to InstSimplify to make sure that stays true. llvm-svn: 348423
* [MachineOutliner][NFC] Remove CandidateList, since it's now unused.Jessica Paquette2018-12-051-29/+11
| | | | | | | After removing the pruning logic, there's no reason to populate a list of Candidates. Remove CandidateList and update comments. llvm-svn: 348422
* Fix buildbot capture warningJessica Paquette2018-12-051-9/+6
| | | | | | | | | | | | | A bot didn't like my lambda. This ought to fix it. Example: http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/30139/steps/build%20lld/logs/stdio error C3493: 'AlreadyRemoved' cannot be implicitly captured because no default capture mode has been specified llvm-svn: 348421
* [MachineOutliner][NFC] Simplify and unify pruning/outlining logicJessica Paquette2018-12-051-157/+15
| | | | | | | | | | | | | | Since we're now performing outlining per OutlinedFunction rather than per Candidate, we can simply outline each candidate as it shows up. Instead of having a pruning phase, instead, we'll outline entire functions. Then we'll update the UnsignedVec we mapped to reflect the deletion. If any candidate is in a space that's marked dirty, then we'll drop it. This lets us remove the pruning logic entirely, and greatly simplifies the code. llvm-svn: 348420
* [InstCombine] reduce duplication in visitExtractElementInst; NFCSanjay Patel2018-12-051-38/+32
| | | | llvm-svn: 348418
* ThinLTO: Do not import debug info for imported global constantsDavid Blaikie2018-12-051-0/+10
| | | | | | | | | | | | | | | | | | | | It looks like this isn't necessary (in any tests I've done, it results in the global being described with no location or value in the imported side - while it's still fully described in the place it's imported from) & results in significant/pathological debug info growth to home these location-less global variable descriptions on the import side. This is a rather pressing/important issue to address - this regressed executable size for one example I'm looking at by 15%, object size is probably similar though I haven't measured it, and a 22x increase in the number of CUs in the cu_index in split DWARF DWP files, creating a similarly large regression in the time it takes llvm-symbolizer to run on such binaries. Reviewers: tejohnson, evgeny777 Differential Revision: https://reviews.llvm.org/D55309 llvm-svn: 348416
* [MachineOutliner] Outline functions by order of benefitJessica Paquette2018-12-051-63/+68
| | | | | | | | | | | | | | | | | | Mostly NFC, only change is the order of outlined function names. Loop over the outlined functions instead of walking the candidate list. This is a bit easier to understand. It's far more natural to create a function, then replace all of its occurrences with calls than the other way around. The functions outlined after this do not change, but their names will be decided by their benefit. E.g, OUTLINED_FUNCTION_0 will now always be the most beneficial function, rather than the first one seen. This makes it easier to enforce an ordering on the outlined functions. So, this also adds a test to make sure that the ordering works as expected. llvm-svn: 348414
* [Hexagon] Add intrinsics for Hexagon V66Krzysztof Parzyszek2018-12-051-0/+30
| | | | llvm-svn: 348413
* [Hexagon] Add instruction definitions for Hexagon V66Krzysztof Parzyszek2018-12-0516-500/+2763
| | | | llvm-svn: 348411
* [Hexagon] Foundation of support for Hexagon V66Krzysztof Parzyszek2018-12-0514-125/+226
| | | | llvm-svn: 348407
* [GISel]: Provide standard interface to observe changes in GISel passesAditya Nandakumar2018-12-0513-73/+119
| | | | | | | | | | | | | https://reviews.llvm.org/D54980 This provides a standard API across GISel passes to observe and notify passes about changes (insertions/deletions/mutations) to MachineInstrs. This patch also removes the recordInsertion method in MachineIRBuilder and instead provides method to setObserver. Reviewed by: vkeles. llvm-svn: 348406
* [CodeExtractor] Do not marked outlined calls which may resume EH as noreturnVedant Kumar2018-12-051-2/+5
| | | | | | | | | | Treat terminators which resume exception propagation as returning instructions (at least, for the purposes of marking outlined functions `noreturn`). This is to avoid inserting traps after calls to outlined functions which unwind. rdar://46129950 llvm-svn: 348404
* [AArch64] Reword description of feature (NFC)Evandro Menezes2018-12-051-2/+2
| | | | | | | Reword the description of the feature that enables custom handling of cheap instructions. llvm-svn: 348398
* [MachineOutliner][NFC] Don't create outlined sequence from integer mappingJessica Paquette2018-12-051-13/+6
| | | | | | | | | | | Some gardening/refactoring. It's cleaner to copy the instructions into the MachineFunction using the first candidate instead of going to the mapper. Also, by doing this we can remove the Seq member from OutlinedFunction entirely. llvm-svn: 348390
* [DAGCombiner] don't try to extract a fraction of a vector binop and crash ↵Sanjay Patel2018-12-051-10/+14
| | | | | | | | | | | | | (PR39893) Because we're potentially peeking through a bitcast in this transform, we need to use overall bitwidths rather than number of elements to determine when it's safe to proceed. Should fix: https://bugs.llvm.org/show_bug.cgi?id=39893 llvm-svn: 348383
* Allow norecurse attribute on functions that have debug infos.Christian Bruel2018-12-051-7/+9
| | | | | | | | | | | | | | Summary: debug intrinsics might be marked norecurse to enable the caller function to be norecurse and optimized if needed. This avoids code gen optimisation differences when -g is used, as in globalOpt.cpp:processInternalGlobal checks. Reviewers: chandlerc, jmolloy, aprantl Reviewed By: aprantl Subscribers: aprantl, llvm-commits Differential Revision: https://reviews.llvm.org/D55187 llvm-svn: 348381
* [SLH] Fix a nasty bug in SLH.Chandler Carruth2018-12-051-1/+3
| | | | | | | | | | | | | | | | | | | | Whenever we effectively take the address of a basic block we need to manually update that basic block to reflect that fact or later passes such as tail duplication and tail merging can break the invariants of the code. =/ Sadly, there doesn't appear to be any good way of automating this or even writing a reasonable assert to catch it early. The change seems trivially and obviously correct, but sadly the only really good test case I have is 1000s of basic blocks. I've tried directly writing a test case that happens to make tail duplication do something that crashes later on, but this appears to require an *amazingly* complex set of conditions that I've not yet reproduced. The change is technically covered by the tests because we mark the blocks as having their address taken, but that doesn't really count as properly testing the functionality. llvm-svn: 348374
* [AMDGPU]: Turn on the DPP combiner by defaultValery Pykhtin2018-12-051-1/+1
| | | | | | Differential revision: https://reviews.llvm.org/D55314 llvm-svn: 348371
* [InstCombine] simplify icmps with same operands based on dominating cmpSanjay Patel2018-12-051-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The tests here are based on the motivating cases from D54827. More background: 1. We don't get these cases in general with SimplifyCFG because the root of the pattern match is an icmp, not a branch. I'm not sure how often we encounter this pattern vs. the seemingly more likely case with branches, but I don't see evidence to leave the minimal pattern unoptimized. 2. This has a chance of increasing compile-time because we're using a ValueTracking call to handle the match. The motivating cases could be handled with a simpler pair of calls to isImpliedTrueByMatchingCmp/ isImpliedFalseByMatchingCmp, but I saw that we have a more comprehensive wrapper around those, so we might as well use it here unless there's evidence that it's significantly slower. 3. Ideally, we'd handle the fold to constants in InstSimplify, but as with the existing code here, we could extend this to handle cases where the result is not a constant, but a new combined predicate. That would mean splitting the logic across the 2 passes and possibly duplicating the pattern-matching cost. 4. As mentioned in D54827, this seems like the kind of thing that should be handled in Correlated Value Propagation, but that pass is currently limited to dealing with instructions with constant operands, so extending this bit of InstCombine is the smallest/easiest way to get these patterns optimized. llvm-svn: 348367
* [X86][SSE] Begun adding modulo rotate support to LowerRotateSimon Pilgrim2018-12-051-4/+12
| | | | | | | | Prep work for PR38243 - mainly adding comments on where we need to add modulo support (doing so at the moment causes massive codegen regressions). I've also consistently added support for modulo folding for uniform constants (although at the moment we have no way to trigger this) and removed the old assertions. llvm-svn: 348366
* [TargetLowering] Remove ISD::ANY_EXTEND/ANY_EXTEND_VECTOR_INREG opcodes from ↵Simon Pilgrim2018-12-051-2/+0
| | | | | | | | SimplifyDemandedVectorElts These have no test coverage and the KnownZero flags can't be guaranteed unlike SIGN/ZERO_EXTEND cases. llvm-svn: 348361
* [SelectionDAG] Initial support for FSHL/FSHR funnel shift opcodes (PR39467)Simon Pilgrim2018-12-059-49/+204
| | | | | | | | | | This is an initial patch to add a minimum level of support for funnel shifts to the SelectionDAG and to begin wiring it up to the X86 SHLD/SHRD instructions. Some partial legalization code has been added to handle the case for 'SlowSHLD' where we want to expand instead and I've added a few DAG combines so we don't get regressions from the existing DAG builder expansion code. Differential Revision: https://reviews.llvm.org/D54698 llvm-svn: 348353
* [MC] - Fix build bot.George Rimar2018-12-051-2/+2
| | | | | | | | | | Error was: /home/buildslave/slave_as-bldslv8/lld-perf-testsuite/llvm/lib/MC/MCFragment.cpp:241:22: error: field 'Offset' will be initialized after field 'LayoutOrder' [-Werror,-Wreorder] Atom(nullptr), Offset(~UINT64_C(0)), LayoutOrder(0) { http://lab.llvm.org:8011/builders/lld-perf-testsuite/builds/9628/steps/build-bin%2Flld/logs/stdio llvm-svn: 348351
OpenPOWER on IntegriCloud