summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* Fix the assembler to print a better relocatable expression errorKevin Enderby2014-04-2210-15/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | diagnostic that includes location information. Currently if one has this assembly: .quad (0x1234 + (4 * SOME_VALUE)) where SOME_VALUE is undefined ones gets the less than useful error message with no location information: % clang -c x.s clang -cc1as: fatal error: error in backend: expected relocatable expression With this fix one now gets a more useful error message with location information: % clang -c x.s x.s:5:8: error: expected relocatable expression .quad (0x1234 + (4 * SOME_VALUE)) ^ To do this I plumbed the SMLoc through the MCObjectStreamer EmitValue() and EmitValueImpl() interfaces so it could be used when creating the MCFixup. rdar://12391022 llvm-svn: 206906
* Simplify address pool index assignment.David Blaikie2014-04-222-6/+2
| | | | llvm-svn: 206905
* R600: Emit error instead of unreachable on function callMatt Arsenault2014-04-222-4/+60
| | | | llvm-svn: 206904
* R600/SI: Reorganize SIInstructions.tdTom Stellard2014-04-221-312/+381
| | | | llvm-svn: 206902
* AVX-512: store and truncstore for i1 valuesElena Demikhovsky2014-04-222-0/+13
| | | | llvm-svn: 206897
* Remove DOS CRLF.NAKAMURA Takumi2014-04-221-6/+6
| | | | llvm-svn: 206894
* AArch64/ARM64: make use of ANDS and BICS instructions for comparisons.Tim Northover2014-04-224-17/+42
| | | | llvm-svn: 206888
* [X86] Require HasBMI2 for the new BZHI tablegen patterns.Lang Hames2014-04-221-20/+22
| | | | | | | Evidently tablegen doesn't infer this from the HasBMI2 predicate on the BZHI instructions. This should fix the recent bot failures. llvm-svn: 206885
* [AVX512] Implemented integer conversions up/down with masking.Robert Khasanov2014-04-221-20/+58
| | | | | | Added encoding tests. llvm-svn: 206884
* [asan] Support outline instrumentation for wide types and delete dead code, ↵Kostya Serebryany2014-04-221-27/+12
| | | | | | patch by Yuri Gribov llvm-svn: 206883
* [X86] Remove Tablegen def of X86bzhi SDNode: It's not needed as of r206879.Lang Hames2014-04-221-1/+0
| | | | llvm-svn: 206880
* [X86] Use tablegen instead of DAG combines to match BZHI instructions, asLang Hames2014-04-223-58/+31
| | | | | | | | suggested by Ben Kramer in review of r206738. Thanks again Ben! llvm-svn: 206879
* [mips] Clang-format MipsAsmParser.Matheus Almeida2014-04-221-33/+32
| | | | | | No functional changes. llvm-svn: 206878
* AArch64/ARM64: add patterns for scalar_to_vector/extract pairsTim Northover2014-04-221-0/+4
| | | | llvm-svn: 206876
* ARM: disable emission of __XYZvfp in soft-float environment.Tim Northover2014-04-221-1/+1
| | | | | | | | | | The point of these calls is to allow Thumb-1 code to make use of the VFP unit to perform its operations. This is not desirable with -msoft-float, since most of the reasons you'd want that apply equally to the runtime library. rdar://problem/13766161 llvm-svn: 206874
* Fix an infinite loop bug in DAG Combine about keeping transfering between ↵Hao Liu2014-04-221-9/+7
| | | | | | ANY_EXTEND and SIGN_EXTEND. llvm-svn: 206873
* [X86] Don't use BZHI for short masks (>=32 bits). Thanks to Ben Kramer for theLang Hames2014-04-221-3/+5
| | | | | | review. llvm-svn: 206869
* Revert "Use value semantics to manage DbgVariables rather than dynamic ↵David Blaikie2014-04-222-57/+54
| | | | | | | | | | | allocation/pointers." This reverts commit r206780. This commit was regressing gdb.opt/inline-locals.exp in the GDB 7.5 test suite. Reverting until I can fix the issue. llvm-svn: 206867
* R600: Change how vector truncating stores are packed.Matt Arsenault2014-04-221-11/+25
| | | | | | | Don't introduce new operations on an illegal sub 32-bit type. Do the operations on a 32-bit value, and then use a truncating store. llvm-svn: 206864
* R600: Make sign_extend_inreg legal.Matt Arsenault2014-04-223-91/+48
| | | | | | Don't know why I didn't just do this in the first place. llvm-svn: 206862
* [AArch64] Enable global merge pass.Jiangning Liu2014-04-223-0/+20
| | | | llvm-svn: 206861
* blockfreq: Skip irreducible backedges inside functionsDuncan P. N. Exon Smith2014-04-221-1/+1
| | | | | | | | | | | | The branch that skips irreducible backedges was only active when propagating mass at the top-level. In particular, when propagating mass through a loop recognized by `LoopInfo` with irreducible control flow inside, irreducible backedges would not be skipped. Not sure where that idea came from, but the result was that mass was lost until after loop exit. Added a testcase that covers this case. llvm-svn: 206860
* blockfreq: Rename PackagedLoops => LoopsDuncan P. N. Exon Smith2014-04-221-1/+1
| | | | llvm-svn: 206859
* blockfreq: Use a pointer for ContainingLoop tooDuncan P. N. Exon Smith2014-04-221-9/+9
| | | | llvm-svn: 206858
* blockfreq: Use pointers to loops instead of an indexDuncan P. N. Exon Smith2014-04-221-4/+5
| | | | | | | | | | | | | Store pointers directly to loops inside the nodes. This could have been done without changing the type stored in `std::vector<>`. However, rather than computing the number of loops before constructing them (which `LoopInfo` doesn't provide directly), I've switched to a `vector<unique_ptr<LoopData>>`. This adds some heap overhead, but the number of loops is typically small. llvm-svn: 206857
* blockfreq: Implement clear() explicitlyDuncan P. N. Exon Smith2014-04-221-1/+5
| | | | | | | | | This was implicitly with copy assignment before, which fails to actually clear `std::vector<>`'s heap storage. Move assignment would work, but since MSVC can't imply those anyway, explicitly `clear()`-ing members makes more sense. llvm-svn: 206856
* blockfreq: Rename PackagedLoopData => LoopDataDuncan P. N. Exon Smith2014-04-221-7/+7
| | | | | | No functionality change. llvm-svn: 206855
* [Modules] Fix potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-222-2/+4
| | | | | | definition below all of the header #include lines, lib/Support edition. llvm-svn: 206847
* [Modules] Fix potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-2215-17/+30
| | | | | | | definition below all the header #include lines. This updates most of the miscellaneous other lib/... directories. A few left though. llvm-svn: 206845
* [Modules] Fix potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-2298-111/+202
| | | | | | | | | | | | | | | | | definition below all of the header #include lines, lib/Transforms/... edition. This one is tricky for two reasons. We again have a couple of passes that define something else before the includes as well. I've sunk their name macros with the DEBUG_TYPE. Also, InstCombine contains headers that need DEBUG_TYPE, so now those headers #define and #undef DEBUG_TYPE around their code, leaving them well formed modular headers. Fixing these headers was a large motivation for all of these changes, as "leaky" macros of this form are hard on the modules implementation. llvm-svn: 206844
* [Modules] Fix potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-2221-25/+44
| | | | | | | | | | definition below all the header #include lines, lib/Analysis/... edition. This one has a bit extra as there were *other* #define's before #include lines in addition to DEBUG_TYPE. I've sunk all of them as a block. llvm-svn: 206843
* [Modules] Fix potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-22152-186/+304
| | | | | | | definition below all of the header #include lines, lib/Target/... edition. llvm-svn: 206842
* [cleanup] Fix two headers where we included a standard library headerChandler Carruth2014-04-222-4/+2
| | | | | | after including the generated code from tablegen. llvm-svn: 206841
* [cleanup] Fix another place where we were including the tablegen'ed codeChandler Carruth2014-04-221-2/+1
| | | | | | | of a '.inc' file before including actual headers. In this case we had both duplicated a header's include and were including a standard header. llvm-svn: 206840
* [cleanup] Lift using directives, DEBUG_TYPE definitions, and even someChandler Carruth2014-04-2248-117/+113
| | | | | | | | | | | | system headers above the includes of generated '.inc' files that actually contain code. In a few targets this was already done pretty consistently, but it wasn't done *really* consistently anywhere. It is strictly cleaner IMO and necessary in a bunch of places where the DEBUG_TYPE is referenced from the generated code. Consistency with the necessary places trumps. Hopefully the build bots are OK with the movement of intrin.h... llvm-svn: 206838
* [Modules] Remove potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-2290-99/+180
| | | | | | | | | | | | define below all header includes in the lib/CodeGen/... tree. While the current modules implementation doesn't check for this kind of ODR violation yet, it is likely to grow support for it in the future. It also removes one layer of macro pollution across all the included headers. Other sub-trees will follow. llvm-svn: 206837
* [CodeGenPrepare] Use APInt to check the value of the immediate in a andQuentin Colombet2014-04-221-2/+2
| | | | | | | | | | while checking candidate for bit field extract. Otherwise the value may not fit in uint64_t and this will trigger an assertion. This fixes PR19503. llvm-svn: 206834
* [Modules] Followup to r206822 to add a DEBUG_TYPE which is used on ARMChandler Carruth2014-04-211-0/+2
| | | | | | and PPC, but not x86. llvm-svn: 206830
* [Modules] Make Support/Debug.h modular. This requires it to not changeChandler Carruth2014-04-2149-2/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | behavior based on other files defining DEBUG_TYPE, which means it cannot define DEBUG_TYPE at all. This is actually better IMO as it forces folks to define relevant DEBUG_TYPEs for their files. However, it requires all files that currently use DEBUG(...) to define a DEBUG_TYPE if they don't already. I've updated all such files in LLVM and will do the same for other upstream projects. This still leaves one important change in how LLVM uses the DEBUG_TYPE macro going forward: we need to only define the macro *after* header files have been #include-ed. Previously, this wasn't possible because Debug.h required the macro to be pre-defined. This commit removes that. By defining DEBUG_TYPE after the includes two things are fixed: - Header files that need to provide a DEBUG_TYPE for some inline code can do so by defining the macro before their inline code and undef-ing it afterward so the macro does not escape. - We no longer have rampant ODR violations due to including headers with different DEBUG_TYPE definitions. This may be mostly an academic violation today, but with modules these types of violations are easy to check for and potentially very relevant. Where necessary to suppor headers with DEBUG_TYPE, I have moved the definitions below the includes in this commit. I plan to move the rest of the DEBUG_TYPE macros in LLVM in subsequent commits; this one is big enough. The comments in Debug.h, which were hilariously out of date already, have been updated to reflect the recommended practice going forward. llvm-svn: 206822
* Set default value of HasExtractBitsInsn to falseYi Jiang2014-04-211-0/+1
| | | | llvm-svn: 206803
* ARM64: Refactor away a few redundant helpers.Jim Grosbach2014-04-211-66/+33
| | | | | | | | | The comment claimed that the register class information wasn't available in the assembly parser, but that's not really true. It's just annoying to get to. Replace the helper functions with references to the auto-generated information. llvm-svn: 206802
* Simplify a vpermil* with constant mask.Rafael Espindola2014-04-211-0/+15
| | | | | | | | With a constant mask a vpermil* is just a shufflevector. This patch implements that simplification. This allows us to produce denser code. It should also allow more folding down the line. llvm-svn: 206801
* ARM64: Improve diagnostics for malformed reg+reg addressing mode.Jim Grosbach2014-04-211-1/+12
| | | | | | | Make sure only general purpose registers are valid for offset regs and that 32-bit regs are only valid for sxtw and uxtw extends. llvm-svn: 206799
* Move helper functions earlier in the file.Jim Grosbach2014-04-211-54/+53
| | | | | | No functional change. llvm-svn: 206798
* ARM64: Extended addressing mode source reg is 64-bit.Jim Grosbach2014-04-211-5/+1
| | | | | | | | | | | | | | The canonical form for the extended addressing mode (e.g., "[x1, w2, uxtw #3]" is for the MCInst to have the second register be the full 64-bit GPR64 register class. The instruction printer cleans up the output for display to show the 32-bit register instead, per the specification. This simplifies 205893 now that the aliasing is handled in the printer in 206495 so that the codegen path and the disassembler path give the same MCInst form. llvm-svn: 206797
* Use unique_ptr to manage ownership of GCOVFunctions, Blocks, and Edges.David Blaikie2014-04-211-36/+21
| | | | llvm-svn: 206796
* Remove seemingly-unneeded artificial dependencyHal Finkel2014-04-211-5/+0
| | | | | | | | | | | | | | | | The rationale for this artificial dependency seems to have been lost to the ravages of time, it is covered by no regression tests, and has no impact on test-suite performance numbers on either x86 or PPC. For the test suite, on both x86 and PPC, I ran the test suite 10 times (both as a baseline and with this change), and found no statistically-significant changes. For PPC, I used a P7 box. For x86, I used an Intel Xeon E5430. Both with -O3 -mcpu=native. This was discussed on-list back in January, but I've not had a chance to run the performance tests until today. llvm-svn: 206795
* Simplify destruction of Modules in LLVContextImpl.David Blaikie2014-04-211-6/+5
| | | | | | | | | | | | | | | | | | | | This avoids copying the container by simply deleting until empty. While I'd rather move to a stricter ownership semantic (unique_ptr), SmallPtrSet can't cope with unique_ptr and the ownership semantics here are a bit incestuous (Module sort of owns itself, but sort of doesn't (if the LLVMContext is destroyed before the Module, then it deregisters itself from the context... )). Ideally Modules would be given to the context, or possibly an emplace-like function to construct them there. Modules then shouldn't be destroyed by LLVM API clients, but by interacting with the owner (LLVMContext) directly (but even then, passing a Module* to LLVMContext doesn't provide an easy way to destroy the Module, since the set would be over unique_ptrs and you'd need a heterogenous lookup function which SmallPtrSet doesn't have either). llvm-svn: 206794
* Handle _GLOBAL_OFFSET_TABLE_ in 64 bit mode.Rafael Espindola2014-04-214-1/+15
| | | | | | | | | With this MC is able to handle _GLOBAL_OFFSET_TABLE_ in 64 bit mode, which is needed for medium and large code models. This fixes pr19470. llvm-svn: 206793
* clang-format this function.Rafael Espindola2014-04-211-5/+10
| | | | | | No functionality change, it will just make the next patch easier to read. llvm-svn: 206792
OpenPOWER on IntegriCloud