summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* Bugfix: SCEVExpander incorrectly marks increment operations as no-wrapSanjoy Das2015-02-251-2/+34
| | | | | | | | | | | | | | | | | | | | | (The change was landed in r230280 and caused the regression PR22674. This version contains a fix and a test-case for PR22674). When emitting the increment operation, SCEVExpander marks the operation as nuw or nsw based on the flags on the preincrement SCEV. This is incorrect because, for instance, it is possible that {-6,+,1} is <nuw> while {-6,+,1}+1 = {-5,+,1} is not. This change teaches SCEV to mark the increment as nuw/nsw only if it can explicitly prove that the increment operation won't overflow. Apart from the attached test case, another (more realistic) manifestation of the bug can be seen in Transforms/IndVarSimplify/pr20680.ll. Differential Revision: http://reviews.llvm.org/D7778 llvm-svn: 230533
* [PowerPC] Cleanup unused target-specific SDAG nodesHal Finkel2015-02-254-35/+7
| | | | | | | | We had somehow accumulated a few target-specific SDAG nodes dealing with PPC64 TOC access that were referenced only in TableGen patterns. The associated (pseudo-)instructions are used, but are being generated directly. NFC. llvm-svn: 230518
* AArch64: Add debug message for large shift constants.Matthias Braun2015-02-251-2/+8
| | | | | | As requested in code review. llvm-svn: 230517
* Fix really obscure bug in CannotBeNegativeZero() (PR22688)Sanjay Patel2015-02-251-1/+7
| | | | | | | | | | With a diabolically crafted test case, we could recurse through this code and return true instead of false. The larger engineering crime is the use of magic numbers. Added FIXME comments for those. llvm-svn: 230515
* [MIPS]Multiple and add instructions for Mips are currently available in ↵Vladimir Medic2015-02-251-14/+14
| | | | | | mips32r2/mips64r2 and later but should also be available in mips4, mips5, and mips64. This patch fixes the requested features and updates the corresponding test files. llvm-svn: 230500
* [X86][MMX] Reapply: Add MMX instructions to foldable tablesBruno Cardoso Lopes2015-02-251-0/+84
| | | | | | | | | | Reapply r230248. Teach the peephole optimizer to work with MMX instructions by adding entries into the foldable tables. This covers folding opportunities not handled during isel. llvm-svn: 230499
* [X86][MMX] Prevent MMX_MOVD64rm foldingBruno Cardoso Lopes2015-02-251-1/+0
| | | | | | | | | | | | | | | MMX_MOVD64rm zero-extends i32 load results into i64 registers. The peephole optimizer will try to fold it in other MMX foldable instructions, the wrong thing to do, since there's no MMX memory instruction that loads from i32 and does implict zero extension. Remove 'canFoldAsLoad' from MOVD64rm in order to prevent such folding. The current MMX tests already test this, but since there are no MMX instructions in the foldable tables yet, this did not trigger. This commit prepares the addition of those instructions. llvm-svn: 230498
* Improve handling of stack accesses in Thumb-1Renato Golin2015-02-254-12/+57
| | | | | | | | | | | | | | | | | Thumb-1 only allows SP-based LDR and STR to be word-sized, and SP-base LDR, STR, and ADD only allow offsets that are a multiple of 4. Make some changes to better make use of these instructions: * Use word loads for anyext byte and halfword loads from the stack. * Enforce 4-byte alignment on objects accessed in this way, to ensure that the offset is valid. * Do the same for objects whose frame index is used, in order to avoid having to use more than one ADD to generate the frame index. * Correct how many bits of offset we think AddrModeT1_s has. Patch by John Brawn. llvm-svn: 230496
* Silencing a "result of 32-bit shift implicitly converted to 64 bits (was ↵Aaron Ballman2015-02-251-1/+1
| | | | | | 64-bit shift intended?)" warning in MSVC; NFC. llvm-svn: 230489
* Silencing a -Wsign-compare warning triggered in MSVC; NFC.Aaron Ballman2015-02-251-1/+1
| | | | llvm-svn: 230488
* Fix UTF8 chars to ASCII.NAKAMURA Takumi2015-02-251-1/+1
| | | | llvm-svn: 230479
* AVX-512: Gather and Scatter patternsElena Demikhovsky2015-02-253-44/+108
| | | | | | | | | | | | | | | Gather and scatter instructions additionally write to one of the source operands - mask register. In this case Gather has 2 destination values - the loaded value and the mask. Till now we did not support code gen pattern for gather - the instruction was generated from intrinsic only and machine node was hardcoded. When we introduce the masked_gather node, we need to select instruction automatically, in the standard way. I added a flag "hasTwoExplicitDefs" that allows to handle 2 destination operands. (Some code in the X86InstrFragmentsSIMD.td is commented out, just to split one big patch in many small patches) llvm-svn: 230471
* [IC] Turn non-null MD on pointer loads to range MD on integer loads.Charles Davis2015-02-252-7/+25
| | | | | | | | | | | | | | | | | Summary: This change fixes the FIXME that you recently added when you committed (a modified version of) my patch. When `InstCombine` combines a load and store of an pointer to those of an equivalently-sized integer, it currently drops any `!nonnull` metadata that might be present. This change replaces `!nonnull` metadata with `!range !{ 1, -1 }` metadata instead. Reviewers: chandlerc Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7621 llvm-svn: 230462
* [opaque pointer type] Bitcode support for explicit type parameter on GEP.David Blaikie2015-02-252-7/+37
| | | | | | | | | | | | | | | | | | | Like r230414, add bitcode support including backwards compatibility, for an explicit type parameter to GEP. At the suggestion of Duncan I tried coalescing the two older bitcodes into a single new bitcode, though I did hit a wrinkle: I couldn't figure out how to create an explicit abbreviation for a record with a variable number of arguments (the indicies to the gep). This means the discriminator between inbounds and non-inbounds gep is a full variable-length field I believe? Is my understanding correct? Is there a way to create such an abbreviation? Should I just use two bitcodes as before? Reviewers: dexonsmith Differential Revision: http://reviews.llvm.org/D7736 llvm-svn: 230415
* [opaque pointer type] bitcode support for explicit type parameter to the ↵David Blaikie2015-02-252-2/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | load instruction Summary: I've taken my best guess at this, but I've cargo culted in places & so explanations/corrections would be great. This seems to pass all the tests (check-all, covering clang and llvm) so I believe that pretty well exercises both the backwards compatibility and common (same version) compatibility given the number of checked in bitcode files we already have. Is that a reasonable approach to testing here? Would some more explicit tests be desired? 1) is this the right way to do back-compat in this case (looking at the number of entries in the bitcode record to disambiguate between the old schema and the new?) 2) I don't quite understand the logarithm logic to choose the encoding type of the type parameter in the abbreviation description, but I found another instruction doing the same thing & it seems to work. Is that the right approach? Reviewers: dexonsmith Differential Revision: http://reviews.llvm.org/D7655 llvm-svn: 230414
* [PowerPC] Add support for the QPX vector instruction setHal Finkel2015-02-2519-67/+2675
| | | | | | | | | | | | | | | | | | | | | | | | | | This adds support for the QPX vector instruction set, which is used by the enhanced A2 cores on the IBM BG/Q supercomputers. QPX vectors are 256 bytes wide, holding 4 double-precision floating-point values. Boolean values, modeled here as <4 x i1> are actually also represented as floating-point values (essentially { -1, 1 } for { false, true }). QPX shares many features with Altivec and VSX, but is distinct from both of them. One major difference is that, instead of adding completely-separate vector registers, QPX vector registers are extensions of the scalar floating-point registers (lane 0 is the corresponding scalar floating-point value). The operations supported on QPX vectors mirrors that supported on the scalar floating-point values (with some additional ones for permutations and logical/comparison operations). I've been maintaining this support out-of-tree, as part of the bgclang project, for several years. This is not the entire bgclang patch set, but is most of the subset that can be cleanly integrated into LLVM proper at this time. Adding this to the LLVM backend is part of my efforts to rebase bgclang to the current LLVM trunk, but is independently useful (especially for codes that use LLVM as a JIT in library form). The assembler/disassembler test coverage is complete. The CodeGen test coverage is not, but I've included some tests, and more will be added as follow-up work. llvm-svn: 230413
* Support SHF_MERGE sections in COMDATs.Rafael Espindola2015-02-251-77/+48
| | | | | | | | | | | | This patch unifies the comdat and non-comdat code paths. By doing this it add missing features to the comdat side and removes the fixed section assumptions from the non-comdat side. In ELF there is no one true section for "4 byte mergeable" constants. We are better off computing the required properties of the section and asking the context for it. llvm-svn: 230411
* BitcodeWriter: Refactor common computation of bits required for a type index.David Blaikie2015-02-253-4/+9
| | | | | | Suggested by Duncan. Happy to bikeshed the name, cache the result, etc. llvm-svn: 230410
* LowerBitSets: Introduce global layout builder.Peter Collingbourne2015-02-241-10/+78
| | | | | | | | | | The builder is based on a layout algorithm that tries to keep members of small bit sets together. The new layout compresses Chromium's bit sets to around 15% of their original size. Differential Revision: http://reviews.llvm.org/D7796 llvm-svn: 230394
* PrologEpilogInserter: Clean up math in calculateFrameObjectOffsetsDavid Majnemer2015-02-241-5/+4
| | | | | | | There is no need to open-code the alignment calculation, we have a handy RoundUpToAlignment function which "Does The Right Thing (TM)". llvm-svn: 230392
* remove function names from comments; NFCSanjay Patel2015-02-241-42/+38
| | | | llvm-svn: 230391
* Reapplied D7816 & rL230177 & rL230278 - with an additional fix toensure that ↵Simon Pilgrim2015-02-241-45/+65
| | | | | | the smallest build vector input scalar type is always used. Additional (crash) test cases already committed. llvm-svn: 230388
* Fixing eol-styleAndrew Kaylor2015-02-241-625/+625
| | | | llvm-svn: 230378
* Revert:Eric Christopher2015-02-241-39/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Author: Simon Pilgrim <llvm-dev@redking.me.uk> Date: Mon Feb 23 23:04:28 2015 +0000 Fix based on post-commit comment on D7816 & rL230177 - BUILD_VECTOR operand truncation was using the the BV's output scalar type instead of the input type. and Author: Simon Pilgrim <llvm-dev@redking.me.uk> Date: Sun Feb 22 18:17:28 2015 +0000 [DagCombiner] Generalized BuildVector Vector Concatenation The CONCAT_VECTORS combiner pass can transform the concat of two BUILD_VECTOR nodes into a single BUILD_VECTOR node. This patch generalises this to support any number of BUILD_VECTOR nodes, and also permits UNDEF nodes to be included as well. This was noticed as AVX vec128 -> vec256 canonicalization sometimes creates a CONCAT_VECTOR with a real vec128 lower and an vec128 UNDEF upper. Differential Revision: http://reviews.llvm.org/D7816 as the root cause of PR22678 which is causing an assertion inside the DAG combiner. I'll follow up to the main thread as well. llvm-svn: 230358
* Rename UpdateRegAllocHint to match style guidelines.Eric Christopher2015-02-243-3/+3
| | | | llvm-svn: 230357
* AArch64: Relax assert about large shift sizes.Matthias Braun2015-02-241-3/+9
| | | | | | | | | | The reason why these large shift sizes happen is because OpaqueConstants currently inhibit alot of DAG combining, but that has to be addressed in another commit (like the proposal in D6946). Differential Revision: http://reviews.llvm.org/D6940 llvm-svn: 230355
* DAGCombiner: Move variable definitions closer to use; NFCMatthias Braun2015-02-241-38/+38
| | | | llvm-svn: 230354
* DAGCombiner: Move variable declaration closer to definiion; NFCMatthias Braun2015-02-241-3/+3
| | | | llvm-svn: 230353
* R600/SI: Remove isel mubuf legalizationTom Stellard2015-02-242-130/+0
| | | | | | | We legalize mubuf instructions post-instruction selection, so this code is no longer needed. llvm-svn: 230352
* ARM: treat [N x i32] and [N x i64] as AAPCS composite typesTim Northover2015-02-244-69/+107
| | | | | | | | | | | The logic is almost there already, with our special homogeneous aggregate handling. Tweaking it like this allows front-ends to emit AAPCS compliant code without ever having to count registers or add discarded padding arguments. Only arrays of i32 and i64 are needed to model AAPCS rules, but I decided to apply the logic to all integer arrays for more consistency. llvm-svn: 230348
* Revert "Raising minimum required CMake version to 2.8.12.2."Tobias Grosser2015-02-242-2/+2
| | | | | | | | | | | This reverts commit r230062. Debian stable (wheezy) ships still with cmake 2.8.9. The commit broke my LLVM/Polly buildbot, to my knowledge our only Linux+cmake buildbot. llvm-svn: 230343
* simplify control flow; NFCSanjay Patel2015-02-241-8/+9
| | | | llvm-svn: 230342
* Revert r230280: "Bugfix: SCEVExpander incorrectly marks increment operations ↵Hans Wennborg2015-02-241-31/+2
| | | | | | | | | | as no-wrap" This caused PR22674, failing this assert: Instructions.h:2281: llvm::Value* llvm::PHINode::getOperand(unsigned int) const: Assertion `i_nocapture < OperandTraits<PHINode>::operands(this) && "getOperand() out of range!"' failed. llvm-svn: 230341
* [x32] Mark RBX as reserved when EBX is the base pointer.Michael Kuperstein2015-02-241-1/+3
| | | | | | This should have gone into r230334. llvm-svn: 230339
* fix typo in comment; NFCSanjay Patel2015-02-241-1/+1
| | | | llvm-svn: 230338
* [x32] x32 should use ebx as the base pointer.Michael Kuperstein2015-02-241-8/+9
| | | | | | This fixes the original issue in PR22655, but not the secondary one. llvm-svn: 230334
* [SDAG] Handle LowerOperation returning its input consistentlyHal Finkel2015-02-242-5/+9
| | | | | | | | | | | | | | | | | | | For almost all node types, if the target requested custom lowering, and LowerOperation returned its input, we'd treat the original node as legal. This did not work, however, for many loads and stores, because they follow slightly different code paths, and we did not account for the possibility of LowerOperation returning its input at those call sites. I think that we now handle this consistently everywhere. At the call sites in LegalizeDAG, we used to assert in this case, so there's no functional change for any existing code there. For the call sites in LegalizeVectorOps, this really only affects whether or not we set Changed = true, but I think makes the semantics clearer. No test case here, but it will be covered by an upcoming PowerPC commit adding QPX support. llvm-svn: 230332
* [mips] Reformat some TableGen definitions. NFC.Toma Tabacu2015-02-242-14/+18
| | | | | | | | | | | | | | Summary: Separated some instruction and pseudo-instruction definitions from InstAlias definitions, added banner for pseudo-instructions and removed a redundant whitespace from a pseudo-instruction definition. No functional change. Reviewers: dsanders Reviewed By: dsanders Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7552 llvm-svn: 230327
* Fix alloca_instruments_all_paddings.cc test to work under higher -O levels ↵Kuba Brecka2015-02-241-7/+5
| | | | | | | | | | (llvm part) When AddressSanitizer only a single dynamic alloca and no static allocas, due to an early exit from FunctionStackPoisoner::poisonStack we forget to unpoison the dynamic alloca. This patch fixes that. Reviewed at http://reviews.llvm.org/D7810 llvm-svn: 230316
* [X86] Remove the AbsMem32 type from the assembly parser. Only really need ↵Craig Topper2015-02-242-12/+2
| | | | | | the 16-bit version which will automatically get prioritized over AbsMem. llvm-svn: 230313
* Beginning of alloca implementation for Mips fast-iselReed Kotler2015-02-241-20/+139
| | | | | | | | | | | | | | | | Summary: Begin to add various address modes; including alloca. Test Plan: Make sure there are no regressions in test-suite at O0/02 in mips32r1/r2 Reviewers: dsanders Reviewed By: dsanders Subscribers: echristo, rfuhler, llvm-commits Differential Revision: http://reviews.llvm.org/D6426 llvm-svn: 230300
* Fix handling of negative offsets for AddrModeT2_i8s4 in rewriteT2FrameIndex.Bob Wilson2015-02-241-5/+2
| | | | | | | | | | | | | | This is a follow up to r230233 to fix something that I noticed by inspection. The AddrModeT2_i8s4 addressing mode does not support negative offsets. I spent a good chunk of the day trying to come up with a testcase for this but was not successful. This addressing mode is used to spill and restore GPRPair registers in Thumb2 code and that does not happen often. We also make very limited used of negative offsets when lowering frame indexes. I am going ahead with the change anyway, because I am pretty confident that it is correct. I also added a missing assertion to check that the low bits of the scaled offset are zero. llvm-svn: 230297
* Fix bug 22641Sanjoy Das2015-02-241-17/+5
| | | | | | | | | | | | | | | The bug was a result of getPreStartForExtend interpreting nsw/nuw flags on an add recurrence more strongly than is legal. {S,+,X}<nsw> implies S+X is nsw only if the backedge of the loop is taken at least once. NOTE: I had accidentally committed an unrelated change with the commit message of this change in r230275 (r230275 was reverted in r230279). This is the correct change for this commit message. Differential Revision: http://reviews.llvm.org/D7808 llvm-svn: 230291
* [LTO API] add lto_codegen_set_module to set the destination module.Manman Ren2015-02-242-0/+20
| | | | | | | | | | | | | | | | | | When debugging LTO issues with ld64, we use -save-temps to save the merged optimized bitcode file, then invoke ld64 again on the single bitcode file to speed up debugging code generation passes and ld64 stuff after code generation. llvm linking a single bitcode file via lto_codegen_add_module will generate a different bitcode file from the single input. With the newly-added lto_codegen_set_module, we can make sure the destination module is the same as the input. lto_codegen_set_module will transfer the ownship of the module to code generator. rdar://19024554 llvm-svn: 230290
* [LoopAccesses] LAA::getInfo to use const reference for stride parameterAdam Nemet2015-02-241-25/+24
| | | | | | And other required const-correctness fixes to make this work. llvm-svn: 230289
* X86: Only use 'lea' in Win64 epilogues if a frame pointer existsDavid Majnemer2015-02-241-7/+21
| | | | | | | We can only use 'add' in epilogues, 'lea' is not permitted unless we've established a frame pointer in the prologue. llvm-svn: 230286
* New instcombine rule: max(~a,~b) -> ~min(a, b)Sanjoy Das2015-02-243-23/+66
| | | | | | | | | | This case is interesting because ScalarEvolutionExpander lowers min(a, b) as ~max(~a,~b). I think the profitability heuristics can be made more clever/aggressive, but this is a start. Differential Revision: http://reviews.llvm.org/D7821 llvm-svn: 230285
* Bugfix: SCEVExpander incorrectly marks increment operations as no-wrapSanjoy Das2015-02-231-2/+31
| | | | | | | | | | | | | | | | | | | | | When emitting the increment operation, SCEVExpander marks the operation as nuw or nsw based on the flags on the preincrement SCEV. This is incorrect because, for instance, it is possible that {-6,+,1} is <nuw> while {-6,+,1}+1 = {-5,+,1} is not. This change teaches SCEV to mark the increment as nuw/nsw only if it can explicitly prove that the increment operation won't overflow. Apart from the attached test case, another (more realistic) manifestation of the bug can be seen in Transforms/IndVarSimplify/pr20680.ll. NOTE: this change was landed with an incorrect commit message in rL230275 and was reverted for that reason in rL230279. This commit message is the correct one. Differential Revision: http://reviews.llvm.org/D7778 llvm-svn: 230280
* Revert 230275.Sanjoy Das2015-02-231-31/+2
| | | | | | | | 230275 got committed with an incorrect commit message due to a mixup on my side. Will re-land in a few moments with the correct commit message. llvm-svn: 230279
* Fix based on post-commit comment on D7816 & rL230177 - BUILD_VECTOR operand ↵Simon Pilgrim2015-02-231-4/+5
| | | | | | truncation was using the the BV's output scalar type instead of the input type. llvm-svn: 230278
OpenPOWER on IntegriCloud