summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Fix PR11985Michael Liao2012-09-121-3/+8
| | | | | | | | | | | - BlockAddress has no support of BA + offset form and there is no way to propagate that offset into machine operand; - Add BA + offset support and a new interface 'getTargetBlockAddress' to simplify target block address forming; - All targets are modified to use new interface and X86 backend is enhanced to support BA + offset addressing. llvm-svn: 163743
* Fix constant folding through bitcasts by no longer relying on undefined ↵Kristof Beyls2012-09-121-2/+2
| | | | | | | | | | | | behaviour (converting NaN values between float and double). SelectionDAG::getConstantFP(double Val, EVT VT, bool isTarget); should not be used when Val is not a simple constant (as the comment in SelectionDAG.h indicates). This patch avoids using this function when folding an unknown constant through a bitcast, where it cannot be guaranteed that Val will be a simple constant. llvm-svn: 163703
* Fold multiply by 0 or 1 when in UnsafeFPMath mode in SelectionDAG::getNode().Michael Ilseman2012-09-101-0/+18
| | | | | | This folding happens as early as possible for performance reasons, and to make sure it isn't foiled by other transforms (e.g. forming FMAs). llvm-svn: 163519
* whitespaceMichael Ilseman2012-09-101-10/+10
| | | | llvm-svn: 163518
* Fix an assertion failure when optimising a shufflevector incorrectly into ↵James Molloy2012-09-101-10/+6
| | | | | | concat_vectors, and a followup bug with SelectionDAG::getNode() creating nodes with invalid types. llvm-svn: 163511
* Add a new optimization pass: Stack Coloring, that merges disjoint static ↵Nadav Rotem2012-09-061-0/+2
| | | | | | | | allocations (allocas). Allocas are known to be disjoint if they are marked by disjoint lifetime markers (@llvm.lifetime.XXX intrinsics). llvm-svn: 163299
* Remove extra MayLoad/MayStore flags from atomic_load/store.Jakob Stoklund Olesen2012-08-281-18/+23
| | | | | | | | | | | | | | | These extra flags are not required to properly order the atomic load/store instructions. SelectionDAGBuilder chains atomics as if they were volatile, and SelectionDAG::getAtomic() sets the isVolatile bit on the memory operands of all atomic operations. The volatile bit is enough to order atomic loads and stores during and after SelectionDAG. This means we set mayLoad on atomic_load, mayStore on atomic_store, and mayLoad+mayStore on the remaining atomic read-modify-write operations. llvm-svn: 162733
* Fix integer undefined behavior due to signed left shift overflow in LLVM.Richard Smith2012-08-241-3/+2
| | | | | | Reviewed offline by chandlerc. llvm-svn: 162623
* Add a roundToIntegral method to APFloat, which can be parameterized over ↵Owen Anderson2012-08-131-0/+18
| | | | | | various rounding modes. Use this to implement SelectionDAG constant folding of FFLOOR, FCEIL, and FTRUNC. llvm-svn: 161807
* Add SelectionDAG::getTargetIndex.Jakob Stoklund Olesen2012-08-071-0/+25
| | | | | | | This adds support for TargetIndex operands during isel. The meaning of these (index, offset, flags) operands is entirely defined by the target. llvm-svn: 161453
* Consider address spaces for hashing and CSEing DAG nodes. Otherwise two ↵Pete Cooper2012-07-301-0/+22
| | | | | | loads from different x86 segments but the same address would get CSEd llvm-svn: 160987
* Replace some explicit compare loops with std::equal.Benjamin Kramer2012-07-191-7/+1
| | | | | | No functionality change. llvm-svn: 160501
* Make ComputeDemandedBits return a deterministic result when computing an ↵Nadav Rotem2012-07-161-0/+1
| | | | | | | | | | | AssertZext value. In the added testcase the constant 55 was behind an AssertZext of type i1, and ComputeDemandedBits reported that some of the bits were both known to be one and known to be zero. Together with Michael Kuperstein <michael.m.kuperstein@intel.com> llvm-svn: 160305
* Refactor the code that checks that all operands of a node are UNDEFs.Nadav Rotem2012-07-151-0/+21
| | | | | | | | | Add a micro-optimization to getNode of CONCAT_VECTORS when both operands are undefs. Can't find a testcase for this because VECTOR_SHUFFLE already handles undef operands, but Duncan suggested that we add this. Together with Michael Kuperstein <michael.m.kuperstein@intel.com> llvm-svn: 160229
* Move lib/Analysis/DebugInfo.cpp to lib/VMCore/DebugInfo.cpp andBill Wendling2012-06-281-4/+4
| | | | | | | | | include/llvm/Analysis/DebugInfo.h to include/llvm/DebugInfo.h. The reasoning is because the DebugInfo module is simply an interface to the debug info MDNodes and has nothing to do with analysis. llvm-svn: 159312
* Change interface for TargetLowering::LowerCallTo and TargetLowering::LowerCallJustin Holewinski2012-05-251-6/+12
| | | | | | | | | | to pass around a struct instead of a large set of individual values. This cleans up the interface and allows more information to be added to the struct for future targets without requiring changes to each and every target. NV_CONTRIB llvm-svn: 157479
* Typo.Chad Rosier2012-05-211-1/+1
| | | | llvm-svn: 157195
* Use dyn_cast instead of checking opcode and cast.Jakub Staszak2012-05-011-2/+1
| | | | llvm-svn: 155957
* Register DAGUpdateListeners with SelectionDAG.Jakob Stoklund Olesen2012-04-201-55/+37
| | | | | | | | | | | | | | | Instead of passing listener pointers to RAUW, let SelectionDAG itself keep a linked list of interested listeners. This makes it possible to have multiple listeners active at once, like RAUWUpdateListener was already doing. It also makes it possible to register listeners up the call stack without controlling all RAUW calls below. DAGUpdateListener uses an RAII pattern to add itself to the SelectionDAG list of active listeners. llvm-svn: 155248
* Move the constant-folding support for FP_ROUND in SelectionDAG from the ↵Owen Anderson2012-04-101-1/+10
| | | | | | | | one-operand version of getNode() to the two-operand version, since it became a two-operand node at sound point. Zap a testcase that this allows us to completely fold away. llvm-svn: 154447
* Treat f16 the same as f80/f128 for the purposes of generating constants ↵Owen Anderson2012-04-051-1/+2
| | | | | | during instruction selection. llvm-svn: 154113
* Always compute all the bits in ComputeMaskedBits.Rafael Espindola2012-04-041-108/+61
| | | | | | | | This allows us to keep passing reduced masks to SimplifyDemandedBits, but know about all the bits if SimplifyDemandedBits fails. This allows instcombine to simplify cases like the one in the included testcase. llvm-svn: 154011
* Teach CodeGen's version of computeMaskedBits to understand the range metadata.Rafael Espindola2012-03-311-6/+10
| | | | | | | | This is the CodeGen equivalent of r153747. I tested that there is not noticeable performance difference with any combination of -O0/-O2 /-g when compiling gcc as a single compilation unit. llvm-svn: 153817
* Checking a build_vector for an all-ones value.Jim Grosbach2012-03-211-5/+14
| | | | | | | | Type legalization can zero-extend the elements of the build_vector node, so, for example, we may have an <8 x i8> with i32 elements of value 255. That should return 'true' for the vector being all ones. llvm-svn: 153203
* Revert r152613 (and r152614), "Inline the d'tor and add an anchor instead." ↵NAKAMURA Takumi2012-03-161-1/+1
| | | | | | | | | for workaround of g++-4.4's miscompilation. It caused MSP430DAGToDAGISel::SelectIndexedBinOp() to be miscompiled. When two ReplaceUses()'s are expanded as inline, vtable in base class is stored to latter (ISelUpdater)ISU. llvm-svn: 152877
* Add a return type.Bill Wendling2012-03-131-1/+1
| | | | llvm-svn: 152614
* Inline the d'tor and add an anchor instead.Bill Wendling2012-03-131-1/+1
| | | | llvm-svn: 152613
* Refactor the SelectionDAG's 'dump' methods into their own .cpp file.Bill Wendling2012-03-131-633/+0
| | | | | | No functionality change. llvm-svn: 152611
* Re-commit r151623 with fix. Only issue special no-return calls if it's a ↵Evan Cheng2012-02-281-6/+9
| | | | | | direct call. llvm-svn: 151645
* Revert r151623 "Some ARM implementaions, e.g. A-series, does return stack ↵Daniel Dunbar2012-02-281-9/+6
| | | | | | prediction. ...", it is breaking the Clang build during the Compiler-RT part. llvm-svn: 151630
* Some ARM implementaions, e.g. A-series, does return stack prediction. That is,Evan Cheng2012-02-281-6/+9
| | | | | | | | | | | | | | | | | the processor keeps a return addresses stack (RAS) which stores the address and the instruction execution state of the instruction after a function-call type branch instruction. Calling a "noreturn" function with normal call instructions (e.g. bl) can corrupt RAS and causes 100% return misprediction so LLVM should use a unconditional branch instead. i.e. mov lr, pc b _foo The "mov lr, pc" is issued in order to get proper backtrace. rdar://8979299 llvm-svn: 151623
OpenPOWER on IntegriCloud