summaryrefslogtreecommitdiffstats
path: root/llvm
Commit message (Collapse)AuthorAgeFilesLines
* [dwarfdump] Make debug_frame dump actually useful.Frederic Riss2015-02-252-15/+148
| | | | | | | | | | | | | | | | | | | | | | | | This adds support for pretty-printing instruction operands. The new output looks like: 00000000 00000010 ffffffff CIE Version: 1 Augmentation: Code alignment factor: 1 Data alignment factor: -4 Return address column: 8 DW_CFA_def_cfa: reg4 +4 DW_CFA_offset: reg8 -4 DW_CFA_nop: DW_CFA_nop: 00000014 00000010 00000000 FDE cie=00000000 pc=00000000...00000022 DW_CFA_advance_loc: 3 DW_CFA_def_cfa_offset: +12 DW_CFA_nop: llvm-svn: 230551
* [dwarfdump] Don't print meaningless pointer.Frederic Riss2015-02-251-3/+0
| | | | | | | CIE pointers were never filled in before, and printing the pointer is totally pointless anyway. llvm-svn: 230550
* DWARFDebugFrame: Move some code around. NFC.Frederic Riss2015-02-251-13/+10
| | | | | | | Move the FrameEntry::dumpInstructions down in the file at some place where it can see the declarations of FDE and CIE. llvm-svn: 230549
* DWARFDebugFrame: Add some trivial accessors. NFC.Frederic Riss2015-02-251-0/+5
| | | | | | To be used for dumping. llvm-svn: 230548
* DWARFDebugFrame: Actually collect CIEs associated with FDEs.Frederic Riss2015-02-251-6/+11
| | | | | | | | This is the first commit in a small series aiming at making debug_frame dump more useful (right now it prints a list of opeartions without their operands). llvm-svn: 230547
* [LTO API] fix memory leakage introduced at r230290.Manman Ren2015-02-252-4/+17
| | | | | | | | r230290 released the LLVM module but not the LTOModule. rdar://19024554 llvm-svn: 230544
* X86, Win64: Allow 'mov' to restore the stack pointer if we have a FPDavid Majnemer2015-02-252-14/+13
| | | | | | | | | | | | | | | | | | The Win64 epilogue structure is very restrictive, it permits a very small number of opcodes and none of them are 'mov'. This means that given: mov %rbp, %rsp pop %rbp The mov isn't the epilogue, only the pop is. This is problematic unless a frame pointer is present in which case we are free to do whatever we'd like in the "body" of the function. If a frame pointer is present, unwinding will undo the prologue operations in reverse order regardless of the fact that we are at an instruction which is reseting the stack pointer. llvm-svn: 230543
* [Orc][Kaleidoscope] Clean up the Orc/Kaleidoscope tutorials to minimize the ↵Lang Hames2015-02-254-168/+187
| | | | | | | | diffs between them. llvm-svn: 230542
* LowerBitSets: Align referenced globals.Peter Collingbourne2015-02-256-73/+101
| | | | | | | | | | | | | | | | This change aligns globals to the next highest power of 2 bytes, up to a maximum of 128. This makes it more likely that we will be able to compress bit sets with a greater alignment. In many more cases, we can now take advantage of a new optimization also introduced in this patch that removes bit set checks if the bit set is all ones. The 128 byte maximum was found to provide the best tradeoff between instruction overhead and data overhead in a recent build of Chromium. It allows us to remove ~2.4MB of instructions at the cost of ~250KB of data. Differential Revision: http://reviews.llvm.org/D7873 llvm-svn: 230540
* [CMake] Fix the clang-cl self host build.Zachary Turner2015-02-252-1/+6
| | | | | | | | | | | | | | This allows clang-cl to self-host cleanly with no magic setup steps required. After this patch, all you have to do is set CC=CXX=clang-cl and run cmake -G Ninja. These changes only exist to support C++ features which are unsupported in clang-cl, so regardless of whether the user specifies they want to use them, we still have to disable them. llvm-svn: 230539
* Fixing a problem with insert location in WinEH outliningAndrew Kaylor2015-02-251-0/+1
| | | | llvm-svn: 230535
* Bugfix: SCEVExpander incorrectly marks increment operations as no-wrapSanjoy Das2015-02-2510-10/+173
| | | | | | | | | | | | | | | | | | | | | (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-252-1/+33
| | | | | | | | | | 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
* fix a typoChris Lattner2015-02-251-1/+1
| | | | llvm-svn: 230510
* [MIPS]Multiple and add instructions for Mips are currently available in ↵Vladimir Medic2015-02-2514-94/+70
| | | | | | 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-253-2/+230
| | | | | | | | | | 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-2513-138/+223
| | | | | | | | | | | | | | | | | 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
* Replace obsolete -mattr=n64 command line option with -target-abi=n64. No ↵Vladimir Medic2015-02-251-6/+6
| | | | | | functional changes. llvm-svn: 230482
* GlobalLayoutBuilder::addFragment(): Prune incorrect usage of \param(s). ↵NAKAMURA Takumi2015-02-251-3/+3
| | | | | | [-Wdocumentation] llvm-svn: 230480
* Fix UTF8 chars to ASCII.NAKAMURA Takumi2015-02-251-1/+1
| | | | llvm-svn: 230479
* AVX-512: Gather and Scatter patternsElena Demikhovsky2015-02-259-50/+141
| | | | | | | | | | | | | | | 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-254-11/+40
| | | | | | | | | | | | | | | | | 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
* Add some missing #includes and forward declarations found by modules build.Richard Smith2015-02-251-3/+7
| | | | llvm-svn: 230457
* build: check if atomic routines are implicitly providedSaleem Abdulrasool2015-02-251-3/+7
| | | | | | | | | | It is possible for the atomic routines to be provided by the compiler without requiring any additional libraries. Check if that is the case before checking for a library. Patch by Matt Glazar! llvm-svn: 230452
* [modules] Add include/llvm/IR/DebugInfoFlags.def to the textual headers list.Richard Smith2015-02-251-0/+1
| | | | llvm-svn: 230427
* [PowerPC] Add triples to QPX testsHal Finkel2015-02-257-0/+7
| | | | | | | Some of these tests fail on Darwin systems because of a lack of a triple; fix that. llvm-svn: 230421
* [GC] Document the recently added PlaceSafepoints and RewriteGCForStatepoints ↵Philip Reames2015-02-251-3/+90
| | | | | | passes llvm-svn: 230420
* llvm-dis: Stop crashing when dropping debug infoDuncan P. N. Exon Smith2015-02-256-5/+52
| | | | | | | | | | | | | | | | | | Since r199356, we've printed a warning when dropping debug info. r225562 started crashing on that, since it registered a diagnostic handler that only expected errors. This fixes the handler to expect other severities. As a side effect, it now prints "error: " at the start of error messages, similar to `llvm-as`. There was a testcase for r199356, but it only really checked the assembler. Move `test/Bitcode/drop-debug-info.ll` to `test/Assembler`, and introduce `test/Bitcode/drop-debug-info.3.5.ll` (and companion `.bc`) to test the bitcode reader. Note: tools/gold/gold-plugin.cpp has an equivalent bug, but I'm not sure what the best fix is there. I'll file a PR. llvm-svn: 230416
* [opaque pointer type] Bitcode support for explicit type parameter on GEP.David Blaikie2015-02-256-14/+56
| | | | | | | | | | | | | | | | | | | 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-2535-68/+4336
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-252-80/+51
| | | | | | | | | | | | 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
* Fix consistently wrong sphinx markupPhilip Reames2015-02-252-25/+25
| | | | | | I'd been using '' where I should have been using ``. llvm-svn: 230407
* Update the GC docs to explicitly mention both gcroot and gc.statepointPhilip Reames2015-02-252-12/+31
| | | | | | Also, fix confusing bit of the gcroot documentation that bit me personally. llvm-svn: 230405
* Make this test even more OS and register allocation neutral.Eric Christopher2015-02-251-16/+16
| | | | llvm-svn: 230404
* [GC] Sync documentation with code namingPhilip Reames2015-02-241-11/+14
| | | | | | Fixing an issue pointed out by Sean Silva. Thanks! llvm-svn: 230403
* More GC documentation cleanupPhilip Reames2015-02-241-21/+24
| | | | llvm-svn: 230402
* Make this test not dependent upon the triple. All that was neededEric Christopher2015-02-241-9/+9
| | | | | | was some flexibility in the check line for the comment basic block. llvm-svn: 230400
* More GC doc cleanupPhilip Reames2015-02-241-41/+51
| | | | | | Mostly minor wording changes for readability. Nothing major to see here. llvm-svn: 230397
* [CMake] Set policy CMP0051 to OLD globally.Zachary Turner2015-02-241-0/+9
| | | | | | | | | | | | | | When you use generator expressions in a library sources list, and then later access the SOURCES property, the OLD behavior (CMake 3.0 and earlier) would not include these expressions in the SOURCES property. The NEW behavior (starting in CMake 3.1) is that they do include the generator expressions in the SOURCES property. Differential Revision: http://reviews.llvm.org/D7870 Reviewed By: Chris Bieneman llvm-svn: 230396
* LowerBitSets: Introduce global layout builder.Peter Collingbourne2015-02-245-12/+210
| | | | | | | | | | 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
* Improve the getting started instructions in the GC docsPhilip Reames2015-02-241-123/+142
| | | | | | This is still gcroot vs gc.statepoint agnostic. I'm just trying to clarify the general documentation at this point. llvm-svn: 230393
* 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
OpenPOWER on IntegriCloud