summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Remove trailing whitespace from SelectionDAG/*.cppStephen Lin2013-07-081-1/+1
| | | | llvm-svn: 185780
* Use SmallVectorImpl instead of SmallVector for iterators and references to ↵Craig Topper2013-07-031-1/+1
| | | | | | avoid specifying the vector size unnecessarily. llvm-svn: 185512
* Access the TargetLoweringInfo from the TargetMachine object instead of ↵Bill Wendling2013-06-191-40/+55
| | | | | | caching it. The TLI may change between functions. No functionality change. llvm-svn: 184360
* Track IR ordering of SelectionDAG nodes 3/4.Andrew Trick2013-05-251-28/+9
| | | | | | | Remove the old IR ordering mechanism and switch to new one. Fix unit test failures. llvm-svn: 182704
* Track IR ordering of SelectionDAG nodes 2/4.Andrew Trick2013-05-251-131/+136
| | | | | | | Change SelectionDAG::getXXXNode() interfaces as well as call sites of these functions to pass in SDLoc instead of DebugLoc. llvm-svn: 182703
* Teach SelectionDAG to constant fold all-constant FMA nodes the same way that ↵Owen Anderson2013-05-091-0/+15
| | | | | | it constant folds FADD, FMUL, etc. llvm-svn: 181555
* Add ArrayRef constructor from None, and do the cleanups that this ↵Dmitri Gribenko2013-05-051-2/+2
| | | | | | | | constructor enables Patch by Robert Wilhelm. llvm-svn: 181138
* Fix constant folding for one lane vector types. Constant folding one lane ↵Silviu Baranga2013-04-251-1/+1
| | | | | | vector types not returns a vector instead of a scalar. llvm-svn: 180254
* ArrayRefize getMachineNode(). No functionality change.Michael Liao2013-04-191-21/+23
| | | | llvm-svn: 179901
* When computing the demanded bits of Load SDNodes, make sure that we are ↵Nadav Rotem2013-03-201-12/+16
| | | | | | | | looking at the loaded-value operand and not the ptr result (in case of pre-inc loads). rdar://13348420 llvm-svn: 177596
* ArrayRefize some code. No functionality change.Benjamin Kramer2013-03-071-2/+2
| | | | llvm-svn: 176648
* Fix PR10475Michael Liao2013-03-011-1/+3
| | | | | | | | | | | | | | - ISD::SHL/SRL/SRA must have either both scalar or both vector operands but TLI.getShiftAmountTy() so far only return scalar type. As a result, backend logic assuming that breaks. - Rename the original TLI.getShiftAmountTy() to TLI.getScalarShiftAmountTy() and re-define TLI.getShiftAmountTy() to return target-specificed scalar type or the same vector type as the 1st operand. - Fix most TICG logic assuming TLI.getShiftAmountTy() a simple scalar type. llvm-svn: 176364
* Fix spelling noticed by Duncan.Chandler Carruth2013-02-251-3/+3
| | | | llvm-svn: 176023
* Fix the root cause of PR15348 by correctly handling alignment 0 onChandler Carruth2013-02-251-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | memory intrinsics in the SDAG builder. When alignment is zero, the lang ref says that *no* alignment assumptions can be made. This is the exact opposite of the internal API contracts of the DAG where alignment 0 indicates that the alignment can be made to be anything desired. There is another, more explicit alignment that is better suited for the role of "no alignment at all": an alignment of 1. Map the intrinsic alignment to this early so that we don't end up generating aligned DAGs. It is really terrifying that we've never seen this before, but we suddenly started generating a large number of alignment 0 memcpys due to the new code to do memcpy-based copying of POD class members. That patch contains a bug that rounds bitfield alignments down when they are the first field. This can in turn produce zero alignments. This fixes weird crashes I've seen in library users of LLVM on 32-bit hosts, etc. llvm-svn: 176022
* Move the SplatByte helper to APInt and generalize it a bit.Benjamin Kramer2013-02-201-13/+3
| | | | llvm-svn: 175621
* SelectionDAG: Teach FoldConstantArithmetic how to deal with vectors.Benjamin Kramer2013-02-041-44/+115
| | | | | | | | | | | | | | | | | This required disabling a PowerPC optimization that did the following: input: x = BUILD_VECTOR <i32 16, i32 16, i32 16, i32 16> lowered to: tmp = BUILD_VECTOR <i32 8, i32 8, i32 8, i32 8> x = ADD tmp, tmp The add now gets folded immediately and we're back at the BUILD_VECTOR we started from. I don't see a way to fix this currently so I left it disabled for now. Fix some trivially foldable X86 tests too. llvm-svn: 174325
* When lowering memcpys to loads and stores, make sure we don't promote alignmentsLang Hames2013-01-311-0/+9
| | | | | | past the natural stack alignment. llvm-svn: 174085
* Make APFloat constructor require explicit semantics.Tim Northover2013-01-221-20/+10
| | | | | | | | | Previously we tried to infer it from the bit width size, with an added IsIEEE argument for the PPC/IEEE 128-bit case, which had a default value. This default value allowed bugs to creep in, where it was inappropriate. llvm-svn: 173138
* Revert 172708.Nadav Rotem2013-01-201-1/+3
| | | | | | | | | The optimization handles esoteric cases but adds a lot of complexity both to the X86 backend and to other backends. This optimization disables an important canonicalization of chains of SEXT nodes and makes SEXT and ZEXT asymmetrical. Disabling the canonicalization of consecutive SEXT nodes into a single node disables other DAG optimizations that assume that there is only one SEXT node. The AVX mask optimizations is one example. Additionally this optimization does not update the cost model. llvm-svn: 172968
* Optimization for the following SIGN_EXTEND pairs:Elena Demikhovsky2013-01-171-3/+1
| | | | | | | | | | | | v8i8 -> v8i64, v8i8 -> v8i32, v4i8 -> v4i64, v4i16 -> v4i64 for AVX and AVX2. Bug 14865. llvm-svn: 172708
* PR14896: Handle memcpy from constant string where the memcpy size is larger ↵Evan Cheng2013-01-101-2/+3
| | | | | | than the string size. llvm-svn: 172124
* Move TargetTransformInfo to live under the Analysis library. This noChandler Carruth2013-01-071-1/+1
| | | | | | | longer would violate any dependency layering and it is in fact an analysis. =] llvm-svn: 171686
* Funnel the actual TargetTransformInfo pass from the SelectionDAGISelChandler Carruth2013-01-051-4/+6
| | | | | | | | | pass into the SelectionDAG itself rather than snooping on the implementation of that pass as exposed by the TargetMachine. This removes the last direct client of the ScalarTargetTransformInfo class outside of the TTI pass implementation. llvm-svn: 171625
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-8/+8
| | | | | | | | | | | | | | | | | | | | | into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
* Resort the #include lines in include/... and lib/... with theChandler Carruth2013-01-021-1/+1
| | | | | | | | | | utils/sort_includes.py script. Most of these are updating the new R600 target and fixing up a few regressions that have creeped in since the last time I sorted the includes. llvm-svn: 171362
* Support ppcf128 in SelectionDAG::getConstantFPHal Finkel2012-12-301-1/+2
| | | | | | | | Fixes pr14751. Patch by Kai; Thanks! llvm-svn: 171261
* Remove the Function::getFnAttributes method in favor of using the AttributeSetBill Wendling2012-12-301-6/+6
| | | | | | | | | directly. This is in preparation for removing the use of the 'Attribute' class as a collection of attributes. That will shift to the AttributeSet class instead. llvm-svn: 171253
* Rename the 'Attributes' class to 'Attribute'. It's going to represent a ↵Bill Wendling2012-12-191-3/+3
| | | | | | single attribute in the future. llvm-svn: 170502
* Fix a logic bug in inline expansion of memcpy / memset with an overlappingEvan Cheng2012-12-121-4/+5
| | | | | | | load / store pair. It's not legal to use a wider load than the size of the remaining bytes if it's the first pair of load / store. llvm-svn: 170018
* Sorry about the churn. One more change to getOptimalMemOpType() hook. Did IEvan Cheng2012-12-121-6/+7
| | | | | | | | | | | | mention the inline memcpy / memset expansion code is a mess? This patch split the ZeroOrLdSrc argument into two: IsMemset and ZeroMemset. The first indicates whether it is expanding a memset or a memcpy / memmove. The later is whether the memset is a memset of zero. It's totally possible (likely even) that targets may want to do different things for memcpy and memset of zero. llvm-svn: 169959
* - Rename isLegalMemOpType to isSafeMemOpType. "Legal" is a very overloade term.Evan Cheng2012-12-121-5/+5
| | | | | | | | | Also added more comments to explain why it is generally ok to return true. - Rename getOptimalMemOpType argument IsZeroVal to ZeroOrLdSrc. It's meant to be true for loaded source (memcpy) or zero constants (memset). The poor name choice is probably some kind of legacy issue. llvm-svn: 169954
* Avoid using lossy load / stores for memcpy / memset expansion. e.g.Evan Cheng2012-12-121-15/+21
| | | | | | f64 load / store on non-SSE2 x86 targets. llvm-svn: 169944
* Replace TargetLowering::isIntImmLegal() withEvan Cheng2012-12-111-1/+5
| | | | | | | | | ScalarTargetTransformInfo::getIntImmCost() instead. "Legal" is a poorly defined term for something like integer immediate materialization. It is always possible to materialize an integer immediate. Whether to use it for memcpy expansion is more a "cost" conceern. llvm-svn: 169929
* Some enhancements for memcpy / memset inline expansion.Evan Cheng2012-12-101-18/+64
| | | | | | | | | | | | | | | | | | | | | 1. Teach it to use overlapping unaligned load / store to copy / set the trailing bytes. e.g. On 86, use two pairs of movups / movaps for 17 - 31 byte copies. 2. Use f64 for memcpy / memset on targets where i64 is not legal but f64 is. e.g. x86 and ARM. 3. When memcpy from a constant string, do *not* replace the load with a constant if it's not possible to materialize an integer immediate with a single instruction (required a new target hook: TLI.isIntImmLegal()). 4. Use unaligned load / stores more aggressively if target hooks indicates they are "fast". 5. Update ARM target hooks to use unaligned load / stores. e.g. vld1.8 / vst1.8. Also increase the threshold to something reasonable (8 for memset, 4 pairs for memcpy). This significantly improves Dhrystone, up to 50% on ARM iOS devices. rdar://12760078 llvm-svn: 169791
* Replace r169459 with something safer. Rather than having computeMaskedBits toEvan Cheng2012-12-061-3/+7
| | | | | | | | | | understand target implementation of any_extend / extload, just generate zero_extend in place of any_extend for liveouts when the target knows the zero_extend will be implicit (e.g. ARM ldrb / ldrh) or folded (e.g. x86 movz). rdar://12771555 llvm-svn: 169536
* Let targets provide hooks that compute known zero and ones for any_extendEvan Cheng2012-12-061-7/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and extload's. If they are implemented as zero-extend, or implicitly zero-extend, then this can enable more demanded bits optimizations. e.g. define void @foo(i16* %ptr, i32 %a) nounwind { entry: %tmp1 = icmp ult i32 %a, 100 br i1 %tmp1, label %bb1, label %bb2 bb1: %tmp2 = load i16* %ptr, align 2 br label %bb2 bb2: %tmp3 = phi i16 [ 0, %entry ], [ %tmp2, %bb1 ] %cmp = icmp ult i16 %tmp3, 24 br i1 %cmp, label %bb3, label %exit bb3: call void @bar() nounwind br label %exit exit: ret void } This compiles to the followings before: push {lr} mov r2, #0 cmp r1, #99 bhi LBB0_2 @ BB#1: @ %bb1 ldrh r2, [r0] LBB0_2: @ %bb2 uxth r0, r2 cmp r0, #23 bhi LBB0_4 @ BB#3: @ %bb3 bl _bar LBB0_4: @ %exit pop {lr} bx lr The uxth is not needed since ldrh implicitly zero-extend the high bits. With this change it's eliminated. rdar://12771555 llvm-svn: 169459
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-21/+21
| | | | | | | | | | | | | | | | | Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
* Revert the majority of the next patch in the address space series:Chandler Carruth2012-11-011-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | r165941: Resubmit the changes to llvm core to update the functions to support different pointer sizes on a per address space basis. Despite this commit log, this change primarily changed stuff outside of VMCore, and those changes do not carry any tests for correctness (or even plausibility), and we have consistently found questionable or flat out incorrect cases in these changes. Most of them are probably correct, but we need to devise a system that makes it more clear when we have handled the address space concerns correctly, and ideally each pass that gets updated would receive an accompanying test case that exercises that pass specificaly w.r.t. alternate address spaces. However, from this commit, I have retained the new C API entry points. Those were an orthogonal change that probably should have been split apart, but they seem entirely good. In several places the changes were very obvious cleanups with no actual multiple address space code added; these I have not reverted when I spotted them. In a few other places there were merge conflicts due to a cleaner solution being implemented later, often not using address spaces at all. In those cases, I've preserved the new code which isn't address space dependent. This is part of my ongoing effort to clean out the partial address space code which carries high risk and low test coverage, and not likely to be finished before the 3.2 release looms closer. Duncan and I would both like to see the above issues addressed before we return to these changes. llvm-svn: 167222
* Revert the series of commits starting with r166578 which introduced theChandler Carruth2012-11-011-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | getIntPtrType support for multiple address spaces via a pointer type, and also introduced a crasher bug in the constant folder reported in PR14233. These commits also contained several problems that should really be addressed before they are re-committed. I have avoided reverting various cleanups to the DataLayout APIs that are reasonable to have moving forward in order to reduce the amount of churn, and minimize the number of commits that were reverted. I've also manually updated merge conflicts and manually arranged for the getIntPtrType function to stay in DataLayout and to be defined in a plausible way after this revert. Thanks to Duncan for working through this exact strategy with me, and Nick Lewycky for tracking down the really annoying crasher this triggered. (Test case to follow in its own commit.) After discussing with Duncan extensively, and based on a note from Micah, I'm going to continue to back out some more of the more problematic patches in this series in order to ensure we go into the LLVM 3.2 branch with a reasonable story here. I'll send a note to llvmdev explaining what's going on and why. Summary of reverted revisions: r166634: Fix a compiler warning with an unused variable. r166607: Add some cleanup to the DataLayout changes requested by Chandler. r166596: Revert "Back out r166591, not sure why this made it through since I cancelled the command. Bleh, sorry about this! r166591: Delete a directory that wasn't supposed to be checked in yet. r166578: Add in support for getIntPtrType to get the pointer type based on the address space. llvm-svn: 167221
* In various places throughout the code generator, there were specialUlrich Weigand2012-10-291-63/+50
| | | | | | | | | checks to avoid performing compile-time arithmetic on PPCDoubleDouble. Now that APFloat supports arithmetic on PPCDoubleDouble, those checks are no longer needed, and we can treat the type like any other. llvm-svn: 166958
* Add in support for getIntPtrType to get the pointer type based on the ↵Micah Villmow2012-10-241-3/+6
| | | | | | | | | address space. This checkin also adds in some tests that utilize these paths and updates some of the clients. llvm-svn: 166578
* Resubmit the changes to llvm core to update the functions to support ↵Micah Villmow2012-10-151-1/+4
| | | | | | different pointer sizes on a per address space basis. llvm-svn: 165941
* Revert 165732 for further review.Micah Villmow2012-10-111-4/+1
| | | | llvm-svn: 165747
* Add in the first iteration of support for llvm/clang/lldb to allow variable ↵Micah Villmow2012-10-111-1/+4
| | | | | | per address space pointer sizes to be optimized correctly. llvm-svn: 165726
* Create enums for the different attributes.Bill Wendling2012-10-091-3/+7
| | | | | | | We use the enums to query whether an Attributes object has that attribute. The opaque layer is responsible for knowing where that specific attribute is stored. llvm-svn: 165488
* Move TargetData to DataLayout.Micah Villmow2012-10-081-14/+14
| | | | llvm-svn: 165402
* Use dyn_cast instead of isa and cast.Jakub Staszak2012-09-301-10/+8
| | | | | | No functionality change. llvm-svn: 164924
* Revert 'Fix a typo 'iff' => 'if''. iff is an abreviation of if and only if. ↵Sylvestre Ledru2012-09-271-5/+5
| | | | | | See: http://en.wikipedia.org/wiki/If_and_only_if Commit 164767 llvm-svn: 164768
* Fix a typo 'iff' => 'if'Sylvestre Ledru2012-09-271-5/+5
| | | | llvm-svn: 164767
* Remove the `hasFnAttr' method from Function.Bill Wendling2012-09-261-3/+3
| | | | | | | The hasFnAttr method has been replaced by querying the Attributes explicitly. No intended functionality change. llvm-svn: 164725
OpenPOWER on IntegriCloud