summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* [DAGCombine] Use getSetCCResultType utility functionHal Finkel2015-08-311-1/+1
| | | | | | | DAGCombine has a utility wrapper around TLI's getSetCCResultType; use it in the one place in DAGCombine still directly calling the TLI function. NFC. llvm-svn: 246482
* [x86] enable machine combiner reassociations for scalar 'or' instsSanjay Patel2015-08-311-0/+4
| | | | llvm-svn: 246481
* [EH] Handle non-Function personalities like unknown personalitiesReid Kleckner2015-08-317-82/+22
| | | | | | | | | Also delete and simplify a lot of MachineModuleInfo code that used to be needed to handle personalities on landingpads. Now that the personality is on the LLVM Function, we no longer need to track it this way on MMI. Certainly it should not live on LandingPadInfo. llvm-svn: 246478
* [FunctionAttr] Infer nonnull attributes on returnsPhilip Reames2015-08-311-0/+148
| | | | | | | | Teach FunctionAttr to infer the nonnull attribute on return values of functions which never return a potentially null value. This is done both via a conservative local analysis for the function itself and a optimistic per-SCC analysis. If no function in the SCC returns anything which could be null (other than values from other functions in the SCC), we can conclude no function returned a null pointer. Even if some function within the SCC returns a null pointer, we may be able to locally conclude that some don't. Differential Revision: http://reviews.llvm.org/D9688 llvm-svn: 246476
* [AArch64][CollectLOH] Remove an invalid assertion and add a test case ↵Quentin Colombet2015-08-311-3/+11
| | | | | | | | exposing it. rdar://problem/22491525 llvm-svn: 246472
* Undo reversion on commit: Revert "Revert "Repress sanitization on User dtor.Naomi Musgrave2015-08-312-2/+6
| | | | | | | | Modify msan macros for applying attribute"" This reverts commit 020e70a79878c96457e6882bcdfaf6628baf32b7. llvm-svn: 246470
* [DAGCombine] Remove some old dead code for forming SETCC nodesHal Finkel2015-08-311-45/+0
| | | | | | | | | | This code was dead when it was committed in r23665 (Oct 7, 2005), and before it reaches its 10th anniversary, it really should go. We can always bring it back if we'd like, but it forms more SETCC nodes, and the way we do legality checking on SETCC nodes is wrong in a number of places, and removing this means fewer places to fix. NFC. llvm-svn: 246466
* [LazyValueInfo] Look through Phi nodes when trying to prove a predicatePhilip Reames2015-08-311-5/+35
| | | | | | | | | | | | | | | | | | If asked to prove a predicate about a value produced by a PHI node, LazyValueInfo was unable to do so even if the predicate was known to be true for each input to the PHI. This prevented JumpThreading from eliminating a provably redundant branch. The problematic test case looks something like this: ListNode *p = ...; while (p != null) { if (!p) return; x = g->x; // unrelated p = p->next } The null check at the top of the loop is redundant since the value of 'p' is null checked on entry to the loop and before executing the backedge. This resulted in us a) executing an extra null check per iteration and b) not being able to LICM unrelated loads after the check since we couldn't prove they would execute or that their dereferenceability wasn't effected by the null check on the first iteration. Differential Revision: http://reviews.llvm.org/D12383 llvm-svn: 246465
* Rework of the new interface for shrink wrappingKit Barton2015-08-312-21/+29
| | | | | | | | | | | | | | | Based on comments from Hal (http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150810/292978.html), I've changed the interface to add a callback mechanism to the TargetFrameLowering class to query whether the specific target supports shrink wrapping. By default, shrink wrapping is disabled by default. Each target can override the default behaviour using the TargetFrameLowering::targetSupportsShrinkWrapping() method. Shrink wrapping can still be explicitly enabled or disabled from the command line, using the existing -enable-shrink-wrap=<true|false> option. Phabricator: http://reviews.llvm.org/D12293 llvm-svn: 246463
* AArch64: Fix loads to lower NEON vector lanes using GPR registersMatthias Braun2015-08-311-1/+4
| | | | | | | | | | | | | The ISelLowering code turned insertion turned the element for the lowest lane of a BUILD_VECTOR into an INSERT_SUBREG, this prohibited the patterns for SCALAR_TO_VECTOR(Load) to match later. Restrict this to cases without a load argument. Reported in rdar://22223823 Differential Revision: http://reviews.llvm.org/D12467 llvm-svn: 246462
* X86: Fix FastISel SSESelect register classMatthias Braun2015-08-311-3/+9
| | | | | | | | | X86FastISel has been using the wrong register class for VBLENDVPS which produces a VR128 and needs an extra copy to the target register. The problem was already hit by the existing test cases when using > llvm-lit -Dllc="llc -verify-machineinstr" llvm-svn: 246461
* [BitcodeReader] Ensure we can read constant vector selects with an i1 conditionFilipe Cabecinhas2015-08-311-4/+5
| | | | | | | | | | | | | | | Summary: Constant vectors weren't allowed to have an i1 condition in the BitcodeReader. Make sure we have the same restrictions that are documented, not more. Reviewers: nlewycky, rafael, kschimpf Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12440 llvm-svn: 246459
* [MC/AsmParser] Avoid setting MCSymbol.IsUsed in some casesVedant Kumar2015-08-311-9/+8
| | | | | | | | | | | | | | | | | | | | Avoid marking some MCSymbols as used in MC/AsmParser.cpp when no uses exist. This fixes a bug in parseAssignmentExpression() which inadvertently sets IsUsed, thereby triggering: "invalid re-assignment of non-absolute variable" on otherwise valid code. No other functionality change intended. The original version of this patch touched many calls to MCSymbol accessors. On rafael's advice, I have stripped this patch down a bit. As a follow-up, I intend to find the call sites which intentionally set IsUsed and force them to do so explicitly. Differential Revision: http://reviews.llvm.org/D12347 llvm-svn: 246457
* Change comment to verify commit accesss.Karl Schimpf2015-08-311-1/+1
| | | | llvm-svn: 246451
* Revert "Repress sanitization on User dtor. Modify msan macros for applying ↵Naomi Musgrave2015-08-312-6/+2
| | | | | | | | attribute" This reverts commit 5e3bfbb38eb3fb6f568b107f6b239e0aa4c5f334. llvm-svn: 246450
* Repress sanitization on User dtor. Modify msan macros for applying attributeNaomi Musgrave2015-08-312-2/+6
| | | | | | | | | | | | | | | to repress sanitization. Move attribute for repressing sanitization to operator delete for User, MDNode. Summary: In response to bug 24578, reported against failing LLVM test. Reviewers: chandlerc, rsmith, eugenis Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12335 llvm-svn: 246449
* [SectionMemoryManager] Use range-based for loops. No functional change intended.Benjamin Kramer2015-08-311-21/+10
| | | | llvm-svn: 246440
* AVX512: ktest implemantationIgor Breger2015-08-314-14/+16
| | | | | | | | Added tests for encoding. Differential Revision: http://reviews.llvm.org/D11979 llvm-svn: 246439
* AVX512: Implemented encoding and intrinsics for vdbpsadbwIgor Breger2015-08-315-1/+15
| | | | | | | | Added tests for intrinsics and encoding. Differential Revision: http://reviews.llvm.org/D12491 llvm-svn: 246436
* AVX512: kadd implementationIgor Breger2015-08-311-2/+4
| | | | | | | | Added tests for encoding. Differential Revision: http://reviews.llvm.org/D11973 llvm-svn: 246432
* AVX512: Implemented encoding and intrinsics for vpalignrIgor Breger2015-08-314-34/+92
| | | | | | | | Added tests for intrinsics and encoding. Differential Revision: http://reviews.llvm.org/D12270 llvm-svn: 246428
* [AggressiveAntiDepBreaker] Check for EarlyClobber on defining instructionHal Finkel2015-08-311-0/+14
| | | | | | | | | AggressiveAntiDepBreaker was doing some EarlyClobber checking, but was not checking that the register being potentially renamed was defined by an early-clobber def where there was also a use, in that instruction, of the register being considered as the target of the rename. Fixes PR24014. llvm-svn: 246423
* [JumpThreading] make jump threading respect convergent annotation.Jingyue Wu2015-08-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: JumpThreading shouldn't duplicate a convergent call, because that would move a convergent call into a control-inequivalent location. For example, if (cond) { ... } else { ... } convergent_call(); if (cond) { ... } else { ... } should not be optimized to if (cond) { ... convergent_call(); ... } else { ... convergent_call(); ... } Test Plan: test/Transforms/JumpThreading/basic.ll Patch by Xuetian Weng. Reviewers: resistor, arsenm, jingyue Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12484 llvm-svn: 246415
* Support: Support LLVM_ENABLE_THREADS=0 in llvm/Support/thread.h.Peter Collingbourne2015-08-311-2/+2
| | | | | | | | Specifically, the header now provides llvm::thread, which is either a typedef of std::thread or a replacement that calls the function synchronously depending on the value of LLVM_ENABLE_THREADS. llvm-svn: 246402
* [PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operandsHal Finkel2015-08-304-5/+168
| | | | | | | | | | | | | | | | | | | | | | There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. llvm-svn: 246400
* NFC: Code style in VectorUtils.cppElena Demikhovsky2015-08-301-10/+12
| | | | | | Differential Revision: http://reviews.llvm.org/D12478 llvm-svn: 246381
* Revert "Revert "New interface function is added to VectorUtils Value ↵Renato Golin2015-08-302-17/+39
| | | | | | | | | *getSplatValue(Value *Val);"" This reverts commit r246379. It seems that the commit was not the culprit, and the bot will be investigated for instability. llvm-svn: 246380
* Revert "New interface function is added to VectorUtils Value ↵Renato Golin2015-08-302-39/+17
| | | | | | | | | | *getSplatValue(Value *Val);" This reverts commit r246371, as it cause a rather obscure bug in AArch64 test-suite paq8p (time outs, seg-faults). I'll investigate it before reapplying. llvm-svn: 246379
* Stop calling the flat out insane ARM target parsing code unless theChandler Carruth2015-08-301-8/+20
| | | | | | | | | | | | | | | | | | | | | | | architecture string is something quite weird. Similarly delay calling the BPF parsing code, although that is more reasonable. To understand why I was motivated to make this change, it cuts the time for running the ADT TripleTest unittests by a factor of two in non-optimized builds (the developer default) and reduces my 'check-llvm' time by a full 15 seconds. The implementation of parseARMArch is *that* slow. I tried to fix it in the prior series of commits, but frankly, I have no idea how to finish fixing it. The entire premise of the function (to allow 'v7a-unknown-linux' or some such to parse as an 'arm-unknown-linux' triple) seems completely insane to me, but I'll let the ARM folks sort that out. At least it is now out of the critical path of every developer working on LLVM. It also will likely make some other folks' code significantly faster as I've heard reports of 2% of time spent in triple parsing even in optimized builds! I'm not done making this code faster, but I am done trying to improve the ARM target parsing code. llvm-svn: 246378
* Remove a linear walk to find the default FPU for a given CPU by directlyChandler Carruth2015-08-301-7/+6
| | | | | | expanding the .def file within a StringSwitch. llvm-svn: 246377
* [MIR Serialization] static -> static const in ↵Hal Finkel2015-08-303-5/+5
| | | | | | | | | getSerializable*MachineOperandTargetFlags Make the arrays 'static const' instead of just 'static'. Post-commit review comment from Roman Divacky on IRC. NFC. llvm-svn: 246376
* Teach the target parsing framework to directly compute the length of allChandler Carruth2015-08-302-45/+72
| | | | | | | | | | of its strings when expanding the string literals from the macros, and push all of the APIs to be StringRef instead of C-string APIs. This (remarkably) removes a very non-trivial number of strlen calls. It even deletes code and complexity from one of the primary users -- Clang. llvm-svn: 246374
* [PowerPC/MIR Serialization] Target flags serialization supportHal Finkel2015-08-302-0/+41
| | | | | | | | | | | | | Add support for MIR serialization of PowerPC-specific operand target flags (based on the generic infrastructure added in r244185 and r245383). I won't even pretend that this is good test coverage, but this includes the regression test associated with r246372. Adding an MIR test for that fix is far superior to adding an IR-level test because particular instruction-scheduling decisions are necessary in order to expose the bug, and using an MIR test we can start the pipeline post-scheduling. llvm-svn: 246373
* [PowerPC] Don't assume ADDISdtprelHA's source is r3Hal Finkel2015-08-301-5/+5
| | | | | | | | | | | | Even through ADDISdtprelHA generally has r3 as its source register, it is possible for the instruction scheduler to move things around such that some other register is the source. We need to print the actual source register, not always r3. Fixes PR24394. The test case will come in a follow-up commit because it depends on MIR target-flags parsing. llvm-svn: 246372
* New interface function is added to VectorUtilsElena Demikhovsky2015-08-302-17/+39
| | | | | | | | | | | | | Value *getSplatValue(Value *Val); It complements the CreateVectorSplat(), which creates 2 instructions - insertelement and shuffle with all-zero mask. The new function recognizes the pattern - insertelement+shuffle and returns the splat value (or nullptr). It also returns a splat value form ConstantDataVector, for completeness. Differential Revision: http://reviews.llvm.org/D11124 llvm-svn: 246371
* Refactor the ARM target parsing to use a def file with macros to expandChandler Carruth2015-08-301-164/+14
| | | | | | | | | | | | | | the necessary tables. This will allow me to restructure the code and structures using this to be significantly more efficient. It also removes the duplication of the list of several enumerators. It also enshrines that the order of enumerators match the order of the entries in the tables, something the implementation code actually uses. No functionality changed (yet). llvm-svn: 246370
* [Triple] Use clang-format to normalize the formatting of the ARM targetChandler Carruth2015-08-301-36/+35
| | | | | | | | | | | | | parsing logic prior to making substantial changes to it. This parsing logic is incredibly wasteful, so I'm planning to rewrite it. Just unittesting the triple parsing logic spends well over 80% of its time in the ARM parsing logic, and others have measured significant time spent here in real production compiles. Stay tuned... llvm-svn: 246369
* [Triple] Stop abusing a class to have only static methods and just useChandler Carruth2015-08-305-49/+49
| | | | | | | the namespace that we are already using for the enums that are produced by the parsing. llvm-svn: 246367
* SelectionDAG: add missing ComputeSignBits case for SELECT_CCFiona Glaser2015-08-291-0/+5
| | | | | | Identical to SELECT, just with different operand numbers. llvm-svn: 246366
* Fix shared library build.Peter Collingbourne2015-08-291-0/+7
| | | | llvm-svn: 246365
* [ARM] Hoist fabs/fneg above a conversion to float.James Molloy2015-08-291-1/+16
| | | | | | | | | | | | | | | | | | This is especially visible in softfp mode, for example in the implementation of libm fabs/fneg functions. If we have: %1 = vmovdrr r0, r1 %2 = fabs %1 then move the fabs before the vmovdrr: %1 = and r1, #0x7FFFFFFF %2 = vmovdrr r0, r1 This is never a lose, and could be a serious win because the vmovdrr may be followed by a vmovrrd, which would enable us to remove the conversion into FPRs completely. We already do this for f32, but not for f64. Tests are added for both. llvm-svn: 246360
* AMDGPU: Add sdst operand to VOP2b instructionsMatt Arsenault2015-08-292-20/+30
| | | | | | | | | | The VOP3 encoding of these allows any SGPR pair for the i1 output, but this was forced before to always use vcc. This doesn't yet try to use this, but does add the operand to the definitions so the main change is adding vcc to the output of the VOP2 encoding. llvm-svn: 246358
* AMDGPU: Set mem operands for spill instructionsMatt Arsenault2015-08-293-25/+55
| | | | llvm-svn: 246357
* AMDGPU: Fix dropping mem operands when moving to VALUMatt Arsenault2015-08-291-11/+12
| | | | | | | | | | | | | Without a memory operand, mayLoad or mayStore instructions are treated as hasUnorderedMemRef, which results in much worse scheduling. We really should have a verifier check that any non-side effecting mayLoad or mayStore has a memory operand. There are a few instructions (interp and images) which I'm not sure what / where to add these. llvm-svn: 246356
* AMDGPU/SI: Fix some invaild assumptions when folding 64-bit immediatesTom Stellard2015-08-291-1/+5
| | | | | | | | | | | | | | | Summary: We were assuming tha if the use operand had a sub-register that the immediate was 64-bits, but this was breaking the case of folding a 64-bit immediate into another 64-bit instruction. Reviewers: arsenm Subscribers: arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D12255 llvm-svn: 246354
* AMDGPU/SI: Factor operand folding code into its own functionTom Stellard2015-08-281-67/+79
| | | | | | | | | | Reviewers: arsenm Subscribers: arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D12254 llvm-svn: 246353
* DI: Set DILexicalBlock columns >= 65536 to 0/unknownDuncan P. N. Exon Smith2015-08-281-0/+3
| | | | | | | | | This fixes PR24621 and matches what we do for `DILocation`. Although the limit seems somewhat artificial, there are places in the backend that also assume 16-bit columns, so we may as well just be consistent about the limits. llvm-svn: 246349
* [X86] NFC: Clean up and clang-format a few linesVedant Kumar2015-08-281-5/+5
| | | | llvm-svn: 246340
* DI: Add Function::getSubprogram()Duncan P. N. Exon Smith2015-08-282-1/+21
| | | | | | | | | | | | | | | | | | Add `Function::setSubprogram()` and `Function::getSubprogram()`, convenience methods to forward to `setMetadata()` and `getMetadata()`, respectively, and deal in `DISubprogram` instead of `MDNode`. Also add a verifier check to enforce that `!dbg` attachments are always subprograms. Originally (when I had the llvm-dev discussion back in April) I thought I'd store a pointer directly on `llvm::Function` for these attachments -- we frequently have debug info, and that's much cheaper than using map in the context if there are no other function-level attachments -- but for now I'm just using the generic infrastructure. Let's add the extra complexity only if this shows up in a profile. llvm-svn: 246339
* AsmPrinter: Allow null subroutine typeDuncan P. N. Exon Smith2015-08-282-8/+3
| | | | | | | | | | | | | | | | | | | | | | Currently the DWARF backend requires that subprograms have a type, and the type is ignored if it has an empty type array. The long term direction here -- see PR23079 -- is instead to skip the type entirely if there's no valid type. It turns out we have cases in tree of missing types on subprograms, but since they're not referenced by compile units, the backend never crashes on them. One option would be to add a Verifier check that subprograms have types, and fix the bitrot. However, this is a fair bit of churn (20-30 testcases) that would be reversed anyway by PR23079. I found this inconsistency because of a WIP patch and upgrade script for PR23367 that started crashing on test/DebugInfo/2010-10-01-crash.ll. This commit updates the testcase to reference the subprogram from the compile unit, and fixes the resulting crash (in line with the direction of PR23079). This also updates `DIBuilder` to stop assuming a non-null pointer for the subroutine types. llvm-svn: 246333
OpenPOWER on IntegriCloud