summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* [PowerPC] Don't ever expand BUILD_VECTOR of v2i64 with shufflesHal Finkel2014-03-312-0/+14
| | | | | | | If we have two unique values for a v2i64 build vector, this will always result in two vector loads if we expand using shuffles. Only one is necessary. llvm-svn: 205231
* Add a TLI hook to control when BUILD_VECTOR might be expanded using shufflesHal Finkel2014-03-311-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two general methods for expanding a BUILD_VECTOR node: 1. Use SCALAR_TO_VECTOR on the defined scalar values and then shuffle them together. 2. Build the vector on the stack and then load it. Currently, we use a fixed heuristic: If there are only one or two unique defined values, then we attempt an expansion in terms of SCALAR_TO_VECTOR and vector shuffles (provided that the required shuffle mask is legal). Otherwise, always expand via the stack. Even when SCALAR_TO_VECTOR is not legal, this can still be a good idea depending on what tricks the target can play when lowering the resulting shuffle. If the target can't do anything special, however, and if SCALAR_TO_VECTOR is expanded via the stack, this heuristic leads to sub-optimal code (two stack loads instead of one). Because only the target knows whether the SCALAR_TO_VECTORs and shuffles for a build vector of a particular type are likely to be optimial, this adds a new TLI function: shouldExpandBuildVectorWithShuffles which takes the vector type and the count of unique defined values. If this function returns true, then method (1) will be used, subject to the constraint that all of the necessary shuffles are legal (as determined by isShuffleMaskLegal). If this function returns false, then method (2) is always used. This commit does not enhance the current code to support expanding a build_vector with more than two unique values using shuffles, but I'll commit an implementation of the more-general case shortly. llvm-svn: 205230
* [mips] Rewrite MipsAsmParser and MipsOperand.Daniel Sanders2014-03-318-1017/+864
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Highlights: - Registers are resolved much later (by the render method). Prior to that point, GPR32's/GPR64's are GPR's regardless of register size. Similarly FGR32's/FGR64's/AFGR64's are FGR's regardless of register size or FR mode. Numeric registers can be anything. - All registers are parsed the same way everywhere (even when handling symbol aliasing) - One consequence is that all registers can be specified numerically almost anywhere (e.g. $fccX, $wX). The exception is symbol aliasing but that can be easily resolved. - Removes the need for the hasConsumedDollar hack - Parenthesis and Bracket suffixes are handled generically - Micromips instructions are parsed directly instead of going through the standard encodings first. - rdhwr accepts all 32 registers, and the following instructions that previously xfailed now work: ddiv, ddivu, div, divu, cvt.l.[ds], se[bh], wsbh, floor.w.[ds], c.ngl.d, c.sf.s, dsbh, dshd, madd.s, msub.s, nmadd.s, nmsub.s, swxc1 - Diagnostics involving registers point at the correct character (the $) - There's only one kind of immediate in MipsOperand. LSA immediates are handled by the predicate and renderer. Lowlights: - Hardcoded '$zero' in the div patterns is handled with a hack. MipsOperand::isReg() will return true for a k_RegisterIndex token with Index == 0 and getReg() will return ZERO for this case. Note that it doesn't return ZERO_64 on isGP64() targets. - I haven't cleaned up all of the now-unused functions. Some more of the generic parser could be removed too (integers and relocs for example). - insve.df needed a custom decoder to handle the implicit fourth operand that was needed to make it parse correctly. The difficulty was that the matcher expected a Token<'0'> but gets an Imm<0>. Adding an implicit zero solved this. Reviewers: matheusalmeida, vmedic Reviewed By: matheusalmeida Differential Revision: http://llvm-reviews.chandlerc.com/D3222 llvm-svn: 205229
* Disable each MachineFunctionPass for 'optnone' functions, unless thatPaul Robinson2014-03-3114-0/+42
| | | | | | | pass normally runs at optimization level None, or is part of the register allocation pipeline. llvm-svn: 205228
* [PowerPC] Correct P7 dispatch unit allocation for vector instructionsHal Finkel2014-03-311-16/+8
| | | | llvm-svn: 205222
* This patch fixes LTO's RecordStreamer so that it records symbols in the MCExprTom Roeder2014-03-311-0/+1
| | | | | | | | | | | part of an asm .symver directive as being used. This prevents referenced functions from being internalized and deleted. Without the patch to LTOModule.cpp, the test case will produce the error: LLVM ERROR: A @@ version cannot be undefined. llvm-svn: 205221
* Support: generalise object type handling for WindowsSaleem Abdulrasool2014-03-311-7/+15
| | | | | | | | | This generalises the object file type parsing to all Windows environments. This is used by cygwin as well as MSVC environments for MCJIT. This also makes the triple more similar to Chandler's suggestion of a separate field for the object file format. llvm-svn: 205219
* PR19099 - revert r203483Eli Bendersky2014-03-312-48/+16
| | | | | | | Now that r205212 was committed, r203483 is no longer necessary; it was a temporary workaround that only handled a small number of the problematic cases. llvm-svn: 205216
* ARM: change parameter names of the ELFARMAsmBackend constructorChristian Pirker2014-03-311-2/+2
| | | | | | | I removed the underscore at the beginning of the parameter name, because of a comment from Tim. llvm-svn: 205215
* Test commit.Robert Khasanov2014-03-311-2/+2
| | | | llvm-svn: 205214
* [mips] Fix use of uninitialized value reported by the ↵Daniel Sanders2014-03-311-0/+2
| | | | | | sanitizer-x86_64-linux-bootstrap buildbot llvm-svn: 205213
* Fix for PR19099 - NVPTX produces invalid symbol names.Eli Bendersky2014-03-314-0/+89
| | | | | | | | This is a more thorough fix for the issue than r203483. An IR pass will run before NVPTX codegen to make sure there are no invalid symbol names that can't be consumed by the ptxas assembler. llvm-svn: 205212
* ARM64: add extra patterns for scalar shiftsTim Northover2014-03-311-6/+12
| | | | llvm-svn: 205209
* ARM64: add extra scalar neg pattern & tests.Tim Northover2014-03-311-1/+2
| | | | llvm-svn: 205208
* ARM64: add patterns for scalar sqdmlal & sqdmlsl.Tim Northover2014-03-311-0/+9
| | | | llvm-svn: 205207
* ARM64: add more patterns for commuted fmsub operations.Tim Northover2014-03-311-0/+8
| | | | llvm-svn: 205206
* ARM64: shuffle patterns around for fmin/fmax & add tests.Tim Northover2014-03-311-8/+8
| | | | llvm-svn: 205205
* ARM64: add more scalar patterns for usqadd & suqadd.Tim Northover2014-03-311-7/+11
| | | | llvm-svn: 205204
* ARM64: add more scalar patterns for reciprocal ops.Tim Northover2014-03-311-0/+15
| | | | llvm-svn: 205203
* ARM64: add i64 scalar pattern for @llvm.arm64.absTim Northover2014-03-312-7/+3
| | | | | | This will be used by the Clang front-end code for vabsd_s64. llvm-svn: 205202
* [mips] Implement missing relocations in the integrated assembler.Daniel Sanders2014-03-311-0/+8
| | | | | | | | | | %got_hi, %got_lo, %call_hi, %call_lo, %higher, and %highest are now recognised by MipsAsmParser::getVariantKind(). To prevent future issues with missing entries in this StringSwitch, I've added an assertion to the default case. llvm-svn: 205200
* Revert r205194 - [mips] Removed R_MIPS_GOT. It's identical to R_MIPS_GOT16.Daniel Sanders2014-03-311-0/+1
| | | | | | There's a couple additional bits I missed. llvm-svn: 205195
* [mips] Removed R_MIPS_GOT. It's identical to R_MIPS_GOT16.Daniel Sanders2014-03-311-1/+0
| | | | llvm-svn: 205194
* Capitalize the D in parseDirectiveGpDWord.Rafael Espindola2014-03-311-4/+4
| | | | | | | | DWord seems to be the canonical way to camel case dword in llvm. Thanks to Daniel Sander for noticing. llvm-svn: 205191
* R600/SI: Implement SIInstrInfo::isTriviallyRematerializable()Tom Stellard2014-03-312-0/+15
| | | | llvm-svn: 205188
* R600/SI: Lower i64 SELECT by bitcasting to a vector typeTom Stellard2014-03-312-7/+10
| | | | | | | This allows allows us to replace ISD::EXTRACT_ELEMENT, which is lowered using shifts, with ISD::EXTRACT_VECTOR_ELT, which is a no-op. llvm-svn: 205187
* R600/SI: Return the correct index for VGPRs in getHWRegIndex()Tom Stellard2014-03-311-1/+1
| | | | | | The register index is stored in the low 8-bits of the encoding. llvm-svn: 205186
* Fixed issue with microMIPS JAL instruction.Zoran Jovanovic2014-03-314-15/+4
| | | | | | Differential Revision: http://llvm-reviews.chandlerc.com/D3200 llvm-svn: 205185
* Look at shuffles of build_vectors in DAGCombiner::visitEXTRACT_VECTOR_ELTHal Finkel2014-03-311-7/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | When the loop vectorizer vectorizes code that uses the loop induction variable, we often end up with IR like this: %b1 = insertelement <2 x i32> undef, i32 %v, i32 0 %b2 = shufflevector <2 x i32> %b1, <2 x i32> undef, <2 x i32> zeroinitializer %i = add <2 x i32> %b2, <i32 2, i32 3> If the add in this example is not legal (as is the case on PPC with VSX), it will be scalarized, and we'll end up with a number of extract_vector_elt nodes with the vector shuffle as the input operand, and that vector shuffle is fed by one or more build_vector nodes. By the time that vector operations are expanded, visitEXTRACT_VECTOR_ELT will not create new extract_vector_elt by looking through the vector shuffle (to make sure that no illegal operations are created), and so the extract_vector_elt -> vector shuffle -> build_vector is never simplified to an operand of the build vector. By looking at build_vectors through a shuffle we fix this particular situation, preventing a vector from being built, only to be deconstructed again (for the scalarized add) -- an expensive proposition when this all needs to be done via the stack. We probably want a more comprehensive fix here where we look back recursively through any shuffles to any build_vectors or scalar_to_vectors, etc. but that can come later. llvm-svn: 205179
* ARM64: fix a couple of signed/unsigned comparison warnings.Tim Northover2014-03-312-3/+2
| | | | llvm-svn: 205174
* [yaml2obj] Add support for ELF e_flags.Daniel Sanders2014-03-311-0/+43
| | | | | | | | | | | | | | | | Summary: The FileHeader mapping now accepts an optional Flags sequence that accepts the EF_<arch>_<flag> constants. When not given, Flags defaults to zero. Reviewers: atanasyan Reviewed By: atanasyan CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D3213 llvm-svn: 205173
* Try to fix MSan bootstrap bot: make ARM64Disassembler::getInstruction() ↵Alexey Samsonov2014-03-311-2/+2
| | | | | | always initialize Size argument. llvm-svn: 205171
* Correct OS conditionals following r204977 and r204978.Yaron Keren2014-03-311-5/+3
| | | | | | | | | | | | | | | | | | | | | | Previously, MinGW OS was Triple::MinGW and Cygwin was Triple::Cygwin and now it is Triple::Win32 with Environment being GNU or Cygwin. So, TheTriple.getOS() == Triple::Win32 is replaced by TheTriple.isWindowsMSVCEnvironment() and (TheTriple.getOS() == Triple::MinGW32 || TheTriple.getOS() == Triple::Cygwin) is replaced by TheTriple.isOSCygMing() llvm-svn: 205170
* [C++11] Mark more classes in the X86 target as 'final'.Craig Topper2014-03-316-8/+8
| | | | llvm-svn: 205166
* Mark a couple of the X86 target classes as final. Allows the compiler to ↵Craig Topper2014-03-312-2/+2
| | | | | | de-virtualize some internal calls. llvm-svn: 205165
* ARM64CollectLOH.cpp: Tweak \param. [-Wdocumentation]NAKAMURA Takumi2014-03-311-1/+1
| | | | llvm-svn: 205162
* [ARM64] Fix materialization of an fp128 zero immediate. There currentlyChandler Carruth2014-03-311-2/+3
| | | | | | | | | is not a pattern to lower this with clever instructions that zero the register, so restrict the zero immediate legality special case to f64 and f32 (the only two sizes which fmov seems to directly support). Fixes backend errors when building code such as libxml. llvm-svn: 205161
* [X86] Adjust cost of FP_TO_UINT v8f32->v8i32Adam Nemet2014-03-301-0/+6
| | | | | | | | | | | | | | | There is no direct AVX instruction to convert to unsigned. I have some ideas how we may be able to do this with three vector instructions but the current backend just bails on this to get it scalarized. See the comment why we need to adjust the cost returned by BasicTTI. The test is a bit roundabout (and checks assembly rather than bit code) because I'd like it to work even if at some point we could vectorize this conversion. Fixes <rdar://problem/16371920> llvm-svn: 205159
* PR18929:Stepan Dyatkovskiy2014-03-301-16/+22
| | | | | | | | According to ARM assembler language hash symbol is optional before immediates. For example, see here for more details: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0473j/dom1359731154529.html llvm-svn: 205157
* Make use of previously generated stores in ↵Hal Finkel2014-03-301-4/+33
| | | | | | | | | | | | | | | | | SelectionDAGLegalize::ExpandExtractFromVectorThroughStack When expanding EXTRACT_VECTOR_ELT and EXTRACT_SUBVECTOR using SelectionDAGLegalize::ExpandExtractFromVectorThroughStack, we store the entire vector and then load the piece we want. This is fine in isolation, but generating a new store (and corresponding stack slot) for each extraction ends up producing code of poor quality. When we scalarize a vector operation (using SelectionDAG::UnrollVectorOp for example) we generate one EXTRACT_VECTOR_ELT for each element in the vector. This used to generate one stored copy of the vector for each element in the vector. Now we search the uses of the vector for a suitable store before generating a new one, which results in much more efficient scalarization code. llvm-svn: 205153
* [PowerPC] Handle VSX v2i64 SIGN_EXTEND_INREGHal Finkel2014-03-303-0/+45
| | | | | | | | | | | | | | | | sitofp from v2i32 to v2f64 ends up generating a SIGN_EXTEND_INREG v2i64 node (and similarly for v2i16 and v2i8). Even though there are no sign-extension (or algebraic shifts) for v2i64 types, we can handle v2i32 sign extensions by converting two and from v2i64. The small trick necessary here is to shift the i32 elements into the right lanes before the i32 -> f64 step. This is because of the big Endian nature of the system, we need the i32 portion in the high word of the i64 elements. For v2i16 and v2i8 we can do the same, but we first use the default Altivec shift-based expansion from v2i16 or v2i8 to v2i32 (by casting to v4i32) and then apply the above procedure. llvm-svn: 205146
* [Allocator] Lift the slab size and size threshold into templateChandler Carruth2014-03-302-135/+20
| | | | | | | | | | parameters rather than runtime parameters. There is only one user of these parameters and they are compile time for that user. Making these compile time seems to better reflect their intended usage as well. llvm-svn: 205143
* Don't mark the declarations of the TSan annotation functions as weak.Chandler Carruth2014-03-301-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | That causes references to them to be weak references which can collapse to null if no definition is provided. We call these functions unconditionally, so a definition *must* be provided. Make the definitions provided in the .cpp file weak by re-declaring them as weak just prior to defining them. This should keep compilers which cannot attach the weak attribute to the definition happy while actually resolving the symbols correctly during the link. You might ask yourself upon reading this commit log: how did *any* of this work before? Well, fun story. It turns out we have some code in Support (BumpPtrAllocator) which both uses virtual dispatch and has out-of-line vtables used by that virtual dispatch. If you move the virtual dispatch into its header in *just* the right way, the optimizer gets to devirtualize, and remove all references to the vtable. Then the sad part: the references to this one vtable were the only strong symbol uses in the support library for llvm-tblgen AFAICT. At least, after doing something just like this, these symbols stopped getting their weak definition and random calls to them would segfault instead. Yay software. llvm-svn: 205137
* [ARM64] Fix a heap-use-after-free spotted by ASan.Chandler Carruth2014-03-301-1/+1
| | | | | | | | StringRef::lower() returns a std::string. Better yet, we can now stop thinking about what it returns and write 'auto'. It does the right thing. =] llvm-svn: 205135
* ARM64: uncopy/paste helper functionTim Northover2014-03-301-5/+4
| | | | | | | | | It was doing functional but highly suspect operations on bools due to the more limited shifting operands supported by memory instructions. Should fix some MSVC warnings. llvm-svn: 205134
* ARM64: remove unused variablesTim Northover2014-03-301-4/+0
| | | | llvm-svn: 205133
* ARM64: remove -m32/-m64 mapping with ARM.Tim Northover2014-03-301-2/+2
| | | | | | | This is causing the ARM build-bots to fail since they only include the ARM backend and can't create an ARM64 target. llvm-svn: 205132
* ARM64: override all the things.Tim Northover2014-03-307-149/+148
| | | | | | | | Actually, mostly only those in the top-level directory that already had a "virtual" attached. But it's the thought that counts and it's been a long day. llvm-svn: 205131
* Support: correct Windows normalisationSaleem Abdulrasool2014-03-301-2/+12
| | | | | | | | | | | | | If the environment is unknown and no object file is provided, then assume an "MSVC" environment, otherwise, set the environment to the object file format. In the case that we have a known environment but a non-native file format for Windows (COFF) which is used for MCJIT, then append the custom file format to the triple as an additional component. This fixes the MCJIT tests on Windows. llvm-svn: 205130
* X86Subtarget.h: isTargetWindows() should tell whether he is targeting msvc.NAKAMURA Takumi2014-03-301-2/+1
| | | | | | | FYI, !isWindowsGNUEnvironment() is insufficient. It missed cygwin. FIXME: The name "isTargetWindows" should be fixed. llvm-svn: 205124
OpenPOWER on IntegriCloud