summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target
Commit message (Collapse)AuthorAgeFilesLines
* [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] Make Support/Debug.h modular. This requires it to not changeChandler Carruth2014-04-2132-1/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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
* 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
* 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
* Use unique_ptr to manage objects owned by the ScheduleDAGMI.David Blaikie2014-04-213-4/+5
| | | | llvm-svn: 206784
* Rename X86insrtps to the proper instruction name.Filipe Cabecinhas2014-04-213-15/+15
| | | | | | | | | | | | | | | Summary: The INSERTPS pattern fragment was called insrtps (mising 'e'), which would make it harder to grep for the patterns related to this instruction. Renaming it to use the proper instruction name. Reviewers: nadav CC: llvm-commits Differential Revision: http://reviews.llvm.org/D3443 llvm-svn: 206779
* [Modules] Consolidate the DEBUG_TYPE defines in NVPTX to the top of theChandler Carruth2014-04-212-5/+1
| | | | | | cpp file rather than in the header and then again in the cpp file. llvm-svn: 206778
* ARM64: Combine shifts and uses from different basic block to bit-extract ↵Yi Jiang2014-04-212-3/+39
| | | | | | instruction llvm-svn: 206774
* Appease autoconf build since X86Disassembler.c has been disappeared in r206717.NAKAMURA Takumi2014-04-211-0/+2
| | | | | | It can be reverted a few days later, after X86Disassembler.d is updated not to contain "X86Disassembler.c". llvm-svn: 206758
* Reapply r206732. This time without optimization of branches.Michael Zolotukhin2014-04-211-0/+2
| | | | llvm-svn: 206749
* [C++11] Replace OwningPtr with std::unique_ptr in places where it doesn't ↵Benjamin Kramer2014-04-217-21/+15
| | | | | | | | break the API. No functionality change. llvm-svn: 206740
* [X86] ISEL (and X, <constant mask>) to BZHI when BMI2 is available.Lang Hames2014-04-211-0/+14
| | | | | | | | | | Generating BZHI in the variable mask case, i.e. (and X, (sub (shl 1, N), 1)), was already supported, but we were missing the constant-mask case. This patch fixes that. <rdar://problem/15480077> llvm-svn: 206738
* Revert r206732 which is causing llc to crash on most of the build bots.Chandler Carruth2014-04-211-2/+0
| | | | | | | | Original commit message: Implement builtins for safe division: safe.sdiv.iN, safe.udiv.iN, safe.srem.iN, safe.urem.iN (iN = i8, i61, i32, or i64). llvm-svn: 206735
* Implement builtins for safe division: safe.sdiv.iN, safe.udiv.iN, safe.srem.iN,Michael Zolotukhin2014-04-211-0/+2
| | | | | | safe.urem.iN (iN = i8, i16, i32, or i64). llvm-svn: 206732
* C++ has a bool type! (And C's had one too, for 15 years...)Richard Smith2014-04-202-38/+33
| | | | llvm-svn: 206723
* More C++ification.Richard Smith2014-04-202-226/+165
| | | | llvm-svn: 206722
* Remove some more C junk from these files.Richard Smith2014-04-202-16/+6
| | | | llvm-svn: 206721
* Don't provide two different definitions of ModRMDecision, OpcodeDecision, ↵Richard Smith2014-04-203-37/+23
| | | | | | and ContextDecision in different source files (depending on #define magic). llvm-svn: 206720
* Don't define llvm::X86Disassembler::InstructionSpecifier in different ways inRichard Smith2014-04-202-12/+8
| | | | | | different source files. llvm-svn: 206719
* Maybe if I touch this file the buildbots will actually rerun configure like ↵Richard Smith2014-04-201-1/+1
| | | | | | they need to... llvm-svn: 206718
* What year is it! This file has no reason to be written in C, and has doubly noRichard Smith2014-04-205-109/+103
| | | | | | | | | | reason to expose a global symbol 'decodeInstruction' nor to pollute the global scope with a bunch of external linkage entities (some of which conflict with others elsewhere in LLVM). This is just the initial transition to C++; more cleanups to follow. llvm-svn: 206717
* Remove some empty statementsAlp Toker2014-04-194-4/+4
| | | | | | Cleanup only. llvm-svn: 206710
* Patch by Vadim ChugunovYaron Keren2014-04-191-0/+7
| | | | | | | | | | | Win64 stack unwinder gets confused when execution flow "falls through" after a call to 'noreturn' function. This fixes the "missing epilogue" problem by emitting a trap instruction for IR 'unreachable' on x86_x64-pc-windows. A secondary use for it would be for anyone wanting to make double-sure that 'noreturn' functions, indeed, do not return. llvm-svn: 206684
* Change the ARM assembler to require a :lower16: or :upper16 on non-constantKevin Enderby2014-04-182-5/+29
| | | | | | | | | | | | | | | | | | | | | | expressions for mov instructions instead of silently truncating by default. For the ARM assembler, we want to avoid misleadingly allowing something like "mov r0, <symbol>" especially when we turn it into a movw and the expression <symbol> does not have a :lower16: or :upper16" as part of the expression. We don't want the behavior of silently truncating, which can be unexpected and lead to bugs that are difficult to find since this is an easy mistake to make. This does change the previous behavior of llvm but actually matches an older gnu assembler that would not allow this but print less useful errors of like “invalid constant (0x927c0) after fixup” and “unsupported relocation on symbol foo”. The error for llvm is "immediate expression for mov requires :lower16: or :upper16" with correct location information on the operand as shown in the added test cases. rdar://12342160 llvm-svn: 206669
* [ARM64] Ports the Cortex-A53 Machine Model description from AArch64.Chad Rosier2014-04-183-4/+135
| | | | | | | | | | | | | Summary: This port includes the rudimentary latencies that were provided for the Cortex-A53 Machine Model in the AArch64 backend. It also changes the SchedAlias for COPY in the Cyclone model to an explicit WriteRes mapping to avoid conflicts in other subtargets. Differential Revision: http://reviews.llvm.org/D3427 Patch by Dave Estes <cestes@codeaurora.org>! llvm-svn: 206652
* [X86] Improve buildFromShuffleMostly for AVXAdam Nemet2014-04-181-6/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For a 256-bit BUILD_VECTOR consisting mostly of shuffles of 256-bit vectors, both the BUILD_VECTOR and its operands may need to be legalized in multiple steps. Consider: (v8f32 (BUILD_VECTOR (extract_vector_elt (v8f32 %vreg0,) Constant<1>), (extract_vector_elt %vreg0, Constant<2>), (extract_vector_elt %vreg0, Constant<3>), (extract_vector_elt %vreg0, Constant<4>), (extract_vector_elt %vreg0, Constant<5>), (extract_vector_elt %vreg0, Constant<6>), (extract_vector_elt %vreg0, Constant<7>), %vreg1)) a. We can't build a 256-bit vector efficiently so, we need to split it into two 128-bit vecs and combine them with VINSERTX128. b. Operands like (extract_vector_elt (v8f32 %vreg0), Constant<7>) needs to be split into a VEXTRACTX128 and a further extract_vector_elt from the resulting 128-bit vector. c. The extract_vector_elt from b. is lowered into a shuffle to the first element and a movss. Depending on the order in which we legalize the BUILD_VECTOR and its operands[1], buildFromShuffleMostly may be faced with: (v4f32 (BUILD_VECTOR (extract_vector_elt (vector_shuffle<1,u,u,u> (extract_subvector %vreg0, Constant<4>), undef), Constant<0>), (extract_vector_elt (vector_shuffle<2,u,u,u> (extract_subvector %vreg0, Constant<4>), undef), Constant<0>), (extract_vector_elt (vector_shuffle<3,u,u,u> (extract_subvector %vreg0, Constant<4>), undef), Constant<0>), %vreg1)) In order to figure out the underlying vector and their identity we need to see through the shuffles. [1] Note that the order in which operations and their operands are legalized is only guaranteed in the first iteration of LegalizeDAG. Fixes <rdar://problem/16296956> llvm-svn: 206634
* ARM64: disable generation of .loh directives outside MachO.Tim Northover2014-04-181-1/+2
| | | | | | Part of PR19455. llvm-svn: 206611
* ARM64: don't emit .subsections_via_symbols on ELF.Tim Northover2014-04-181-7/+9
| | | | | | Part of PR19455. llvm-svn: 206610
* ARM64: add extra NEG pattern.Tim Northover2014-04-181-0/+2
| | | | llvm-svn: 206609
* AArch64/ARM64: add non-scalar lowering for more FCVT operations.Tim Northover2014-04-182-2/+12
| | | | llvm-svn: 206591
* AArch64/ARM64: improve spotting of EXT instructions from VECTOR_SHUFFLE.Tim Northover2014-04-181-5/+7
| | | | | | | We couldn't cope if the first mask element was UNDEF before, which isn't ideal. llvm-svn: 206588
* X86: Pattern match scalar loads + vcvtph2ps into just vcvtph2ps.Benjamin Kramer2014-04-181-0/+6
| | | | | | | vcvtph2ps only reads the lower 64 bits of the address passed to the intrinsic. llvm-svn: 206579
* AArch64/ARM64: spot a greater variety of concat_vector operations.Tim Northover2014-04-181-14/+72
| | | | | | | | | | Code mostly copied from AArch64, just tidied up a trifle and plumbed into the ARM64 way of doing things. This also enables the AArch64 tests which inspired the previous untested commits. llvm-svn: 206574
* ARM64: implement cunning optimisation from AArch64Tim Northover2014-04-181-0/+53
| | | | | | | | A vector extract followed by a dup can become a single instruction even if the types don't match. AArch64 handled this in ISelLowering, but a few reasonably simple patterns can take care of it in TableGen, so that's where I've put it. llvm-svn: 206573
* ARM64: spot a vector_shuffle that maps to INS and expand.Tim Northover2014-04-181-0/+64
| | | | | | | Tests will be coming very shortly when all the optimisations needed to support AArch64's neon-copy.ll file are committed. llvm-svn: 206572
* ARM64: nick some AArch64 patterns for extract/insert -> INS.Tim Northover2014-04-181-0/+37
| | | | | | | Tests will be committed shortly when all optimisations needed to support AArch64's neon-copy.ll file are supported. llvm-svn: 206571
* AArch64/ARM64: emit all vector FP comparisons as such.Tim Northover2014-04-181-5/+42
| | | | | | | | | | | | ARM64 was scalarizing some vector comparisons which don't quite map to AArch64's compare and mask instructions. AArch64's approach of sacrificing a little efficiency to emulate them with the limited set available was better, so I ported it across. More "inspired by" than copy/paste since the backend's internal expectations were a bit different, but the tests were invaluable. llvm-svn: 206570
* AArch64/ARM64: port BSL logic from AArch64 & enable test.Tim Northover2014-04-183-0/+75
| | | | | | | | | | | I enhanced it a little in the process. The decision shouldn't really be beased on whether a BUILD_VECTOR is a splat: any set of constants will do the job provided they're related in the correct way. Also, the BUILD_VECTOR could be any operand of the incoming AND nodes, so it's best to check for all 4 possibilities rather than assuming it'll be the RHS. llvm-svn: 206569
* AArch64/ARM64: copy byval implementation from AArch64.Tim Northover2014-04-182-16/+49
| | | | | | | | It's not actually used to handle C or C++ ABI rules on ARM64, but could well be emitted by other language front-ends, so it's as well to have a sensible implementation. llvm-svn: 206568
* This commit allows vectorized loops to be unrolled by a factor of 2 for AArch64.Jiangning Liu2014-04-181-0/+1
| | | | | | | | A new test case is also added for ARM64. Patched by Z.Zheng llvm-svn: 206563
* R600: Minor cleanups.Matt Arsenault2014-04-183-69/+64
| | | | | | Fix indentation, better line wrapping, unused includes. llvm-svn: 206562
* This is one of the optimizations ported from ARM64 to AArch64 to address the ↵Jiangning Liu2014-04-181-0/+2
| | | | | | | | performance gap between these two back ends. The test case newly added for AArch64 already exists in ARM64. Patched by Z.Zheng llvm-svn: 206559
* R600/SI: Try to use scalar BFE.Matt Arsenault2014-04-182-5/+66
| | | | | | | | Use scalar BFE with constant shift and offset when possible. This is complicated by the fact that the scalar version packs the two operands of the vector version into one. llvm-svn: 206558
* This commit enables unaligned memory accesses of vector types on AArch64 ↵Jiangning Liu2014-04-184-0/+91
| | | | | | | | back end. This should boost vectorized code performance. Patched by Z. Zheng llvm-svn: 206557
* R600/SI: Match sign_extend_inreg to s_sext_i32_i8 and s_sext_i32_i16Matt Arsenault2014-04-184-16/+63
| | | | llvm-svn: 206547
* R600/SI: Use SReg_64 instead of VSrc_64 when selecting BUILD_PAIRTom Stellard2014-04-181-1/+1
| | | | llvm-svn: 206541
OpenPOWER on IntegriCloud