summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* Move Intrinsic::objectsize lowering back to InstCombineCalls andEric Christopher2010-02-091-1/+19
| | | | | | enable constant 0 offset lowering. llvm-svn: 95691
* Pull these back out, they're a little too aggressive and timeEric Christopher2010-02-092-115/+0
| | | | | | consuming for a simple optimization. llvm-svn: 95671
* simplify this code, duh.Chris Lattner2010-02-091-8/+4
| | | | llvm-svn: 95643
* fix PR6193, only considering sign extensions *from i1* for thisChris Lattner2010-02-091-5/+10
| | | | | | xform. llvm-svn: 95642
* Add file in here too.Eric Christopher2010-02-091-0/+1
| | | | llvm-svn: 95641
* Add a new pass to do llvm.objsize lowering using SCEV.Eric Christopher2010-02-091-0/+114
| | | | | | | | | | | Initial skeleton and SCEVUnknown lowering implemented, the rest should come relatively quickly. Move testcase to new directory. Move pass to right before SimplifyLibCalls - which is moved down a bit so we can take advantage of a few opts. llvm-svn: 95628
* fix some problems handling large vectors reported in PR6230Chris Lattner2010-02-082-9/+14
| | | | llvm-svn: 95616
* Reintroduce the InlineHint function attribute.Jakob Stoklund Olesen2010-02-061-7/+24
| | | | | | | | | | | | This time it's for real! I am going to hook this up in the frontends as well. The inliner has some experimental heuristics for dealing with the inline hint. When given a -respect-inlinehint option, functions marked with the inline keyword are given a threshold just above the default for -O3. We need some experiments to determine if that is the right thing to do. llvm-svn: 95466
* Don't unroll loops containing function calls.Jakob Stoklund Olesen2010-02-051-2/+8
| | | | llvm-svn: 95454
* Teach SimplifyCFG about magic pointer constants.Jakob Stoklund Olesen2010-02-052-40/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Weird code sometimes uses pointer constants other than null. This patch teaches SimplifyCFG to build switch instructions in those cases. Code like this: void f(const char *x) { if (!x) puts("null"); else if ((uintptr_t)x == 1) puts("one"); else if (x == (char*)2 || x == (char*)3) puts("two"); else if ((intptr_t)x == 4) puts("four"); else puts(x); } Now becomes a switch: define void @f(i8* %x) nounwind ssp { entry: %magicptr23 = ptrtoint i8* %x to i64 ; <i64> [#uses=1] switch i64 %magicptr23, label %if.else16 [ i64 0, label %if.then i64 1, label %if.then2 i64 2, label %if.then9 i64 3, label %if.then9 i64 4, label %if.then14 ] Note that LLVM's own DenseMap uses magic pointers. llvm-svn: 95439
* fix logical-select to invoke filecheck right, and fix hte instcombineChris Lattner2010-02-051-1/+6
| | | | | | | | | xform it is checking to actually pass. There is no need to match m_SelectCst<0, -1> since instcombine canonicalizes that into not(sext). Add matches for sext(not(x)) in addition to not(sext(x)). llvm-svn: 95420
* Implement releaseMemory in CodeGenPrepare and free the BackEdgesDan Gohman2010-02-051-0/+4
| | | | | | | container data. This prevents it from holding onto dangling pointers and potentially behaving unpredictably. llvm-svn: 95409
* Use a SmallSetVector instead of a SetVector; this code showed up as aDan Gohman2010-02-051-2/+3
| | | | | | malloc caller in a profile. llvm-svn: 95407
* Remove this code for now. I have a better idea and will rewrite withEric Christopher2010-02-051-41/+0
| | | | | | that in mind. llvm-svn: 95402
* Do not reassociate expressions with i1 type. SimplifyCFG converts someBob Wilson2010-02-041-0/+9
| | | | | | | | | | short-circuited conditions to AND/OR expressions, and those expressions are often converted back to a short-circuited form in code gen. The original source order may have been optimized to take advantage of the expected values, and if we reassociate them, we change the order and subvert that optimization. Radar 7497329. llvm-svn: 95333
* Increase inliner thresholds by 25.Jakob Stoklund Olesen2010-02-041-3/+3
| | | | | | | | This makes the inliner about as agressive as it was before my changes to the inliner cost calculations. These levels give the same performance and slightly smaller code than before. llvm-svn: 95320
* Temporarily revert this since it appears to have caused a buildEric Christopher2010-02-041-49/+23
| | | | | | failure. llvm-svn: 95294
* Rework constant expr and array handling for objectsize instcombining.Eric Christopher2010-02-041-23/+49
| | | | | | | | | | Fix bugs where we would compute out of bounds as in bounds, and where we couldn't know that the linker could override the size of an array. Add a few new testcases, change existing testcase to use a private global array instead of extern. llvm-svn: 95283
* If we're dealing with a zero-length array, don't lower to anyEric Christopher2010-02-031-4/+9
| | | | | | particular size, we just don't know what the length is yet. llvm-svn: 95266
* Adjust the heuristics used to decide when SROA is likely to be profitable.Bob Wilson2010-02-031-18/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The SRThreshold value makes perfect sense for checking if an entire aggregate should be promoted to a scalar integer, but it is not so good for splitting an aggregate into its separate elements. A struct may contain a large embedded array along with some scalar fields that would benefit from being split apart by SROA. Even if the total aggregate size is large, it may still be good to perform SROA. Thus, the most important piece of this patch is simply moving the aggregate size comparison vs. SRThreshold so that it guards only the aggregate promotion. We have also been checking the number of elements to decide if an aggregate should be split up. The limit of "SRThreshold/4" seemed rather arbitrary, and I don't think it's very useful to derive this limit from SRThreshold anyway. I've collected some data showing that the current default limit of 32 (since SRThreshold defaults to 128) is a reasonable cutoff for struct types. One thing suggested by the data is that distinguishing between structs and arrays might be useful. There are (obviously) a lot more large arrays than large structs (as measured by the number of elements and not the total size -- a large array inside a struct still counts as a single element given the way we do SROA right now). Out of 8377 arrays where we successfully performed SROA while compiling a large set of benchmarks, only 16 of them had more than 8 elements. And, for those 16 arrays, it's not at all clear that SROA was actually beneficial. So, to offset the compile time cost of investigating more large structs for SROA, the patch lowers the limit on array elements to 8. This fixes Apple Radar 7563690. llvm-svn: 95224
* Revert 94937 and move the noreturn check to codegen.Evan Cheng2010-02-031-5/+4
| | | | llvm-svn: 95198
* Fix some comment typos.Bob Wilson2010-02-031-3/+3
| | | | llvm-svn: 95170
* Recommit this, looks like it wasn't the cause.Eric Christopher2010-02-032-70/+100
| | | | llvm-svn: 95165
* Hopefully temporarily revert this.Eric Christopher2010-02-022-100/+70
| | | | llvm-svn: 95154
* Reformat my last patch slightly.Eric Christopher2010-02-021-4/+4
| | | | llvm-svn: 95147
* Re-add strcmp and known size object size checking optimization.Eric Christopher2010-02-022-12/+41
| | | | | | Passed bootstrap and nightly test run here. llvm-svn: 95145
* don't turn (A & (C0?-1:0)) | (B & ~(C0?-1:0)) -> C0 ? A : BChris Lattner2010-02-021-9/+13
| | | | | | | for vectors. Codegen is generating awful code or segfaulting in various cases (e.g. PR6204). llvm-svn: 95058
* fix a crash in loop unswitch on a loop invariant vector condition.Chris Lattner2010-02-021-1/+5
| | | | llvm-svn: 95055
* LangRef.html says that inttoptr and ptrtoint always use zero-extensionDan Gohman2010-02-021-21/+32
| | | | | | when the cast is extending. llvm-svn: 95046
* Don't need to check the last argument since it'll always be bool. We alsoEric Christopher2010-02-021-5/+1
| | | | | | don't use TargetData here. llvm-svn: 95040
* More indentation/tabification fixes.Eric Christopher2010-02-021-13/+13
| | | | llvm-svn: 95036
* Untabify previous commit.Eric Christopher2010-02-021-3/+3
| | | | llvm-svn: 95035
* Formatting.Eric Christopher2010-02-011-3/+3
| | | | llvm-svn: 95027
* Add an option to GVN to remove all partially redundant loads. This is currentlyBob Wilson2010-02-011-80/+107
| | | | | | | | | disabled by default. This divides the existing load PRE code into 2 phases: first it checks that it is safe to move the load to each of the predecessors where it is unavailable, and then if it is safe, the code is changed to move the load. Radar 7571861. llvm-svn: 95007
* cleanups.Chris Lattner2010-02-011-4/+4
| | | | llvm-svn: 94995
* fix rdar://7590304, a miscompilation of objc apps on arm. The callerChris Lattner2010-02-011-3/+7
| | | | | | | | | of objc message send was getting marked arm_apcscc, but the prototype isn't. This is fine at runtime because objcmsgsend is implemented in assembly. Only turn a mismatched caller and callee into 'unreachable' if the callee is a definition. llvm-svn: 94986
* fix rdar://7590304, an infinite loop in instcombine. In the invokeChris Lattner2010-02-011-1/+6
| | | | | | | | | | | | | case, instcombine can't zap the invoke for fear of changing the CFG. However, we have to do something to prevent the next iteration of instcombine from inserting another store -> undef before the invoke thereby getting into infinite iteration between dead store elim and store insertion. Just zap the callee to null, which will prevent the next iteration from doing anything. llvm-svn: 94985
* Fix pr6198 by moving the isSized() check to an outer conditional.Bob Wilson2010-02-011-6/+8
| | | | | | | The testcase from pr6198 does not crash for me -- I don't know what's up with that -- so I'm not adding it to the tests. llvm-svn: 94984
* Simplify/generalize the xor+add->sign-extend instcombine.Eli Friedman2010-01-311-35/+19
| | | | llvm-svn: 94943
* Add a small transform: transform -(X<<Y) to (-X<<Y) when the shift has a singleEli Friedman2010-01-311-0/+7
| | | | | | use and X is free to negate. llvm-svn: 94941
* Do not mark no-return calls tail calls. It'll screw up special calls like ↵Evan Cheng2010-01-311-4/+5
| | | | | | longjmp and it doesn't make much sense for performance reason. If my logic is faulty, please let me know. llvm-svn: 94937
* Check alignment of loads when deciding whether it is safe to execute themBob Wilson2010-01-304-15/+25
| | | | | | | unconditionally. Besides checking the offset, also check that the underlying object is aligned as much as the load itself. llvm-svn: 94875
* Use more specific types to avoid casts. No functionality change.Bob Wilson2010-01-301-6/+6
| | | | llvm-svn: 94863
* Keep iterating over all uses when meeting a phi node in ↵Jakob Stoklund Olesen2010-01-291-2/+2
| | | | | | | | | | | AllUsesOfValueWillTrapIfNull(). This bug was exposed by my inliner cost changes in r94615, and caused failures of lencod on most architectures when building with LTO. This patch fixes lencod and 464.h264ref on x86-64 (and likely others). llvm-svn: 94858
* Preserve load alignment in instcombine transformations. I've been unable toBob Wilson2010-01-291-0/+3
| | | | | | | | | | create a testcase where this matters. The select+load transformation only occurs when isSafeToLoadUnconditionally is true, and in those situations, instcombine also changes the underlying objects to be aligned. This seems like a good idea regardless, and I've verified that it doesn't pessimize the subsequent realignment. llvm-svn: 94850
* Revert my last couple of patches. They appear to have broken bison.Eric Christopher2010-01-292-43/+15
| | | | llvm-svn: 94841
* Use uint64_t instead of unsigned for offsets and sizes.Bob Wilson2010-01-291-3/+3
| | | | llvm-svn: 94835
* Improve isSafeToLoadUnconditionally to recognize that GEPs with constantBob Wilson2010-01-293-11/+65
| | | | | | | indices are safe if the result is known to be within the bounds of the underlying object. llvm-svn: 94829
* Having RHSKnownZero and RHSKnownOne be alternative names for KnownZero and ↵Duncan Sands2010-01-291-75/+69
| | | | | | | | | | | KnownOne (via APInt &RHSKnownZero = KnownZero, etc) seems dangerous and confusing to me: it is easy not to notice this, and then wonder why KnownZero/RHSKnownZero changed underneath you when you modified RHSKnownZero/KnownZero etc. So get rid of this. No intended functionality change (tested with "make check" + llvm-gcc bootstrap). llvm-svn: 94802
* Make strcpy_chk lower to strcpy if we have a safe size.Eric Christopher2010-01-291-5/+7
| | | | llvm-svn: 94783
OpenPOWER on IntegriCloud