summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/IPO
Commit message (Collapse)AuthorAgeFilesLines
* Use the target-aware constant folder on expressions to improve the chanceNick Lewycky2012-02-211-2/+9
| | | | | | | | | | | | | they'll be simple enough to simulate, and to reduce the chance we'll encounter equal but different simple pointer constants. This removes the symptoms from PR11352 but is not a full fix. A proper fix would either require a guarantee that two constant objects we simulate are folded when equal, or a different way of handling equal pointers (ie., trying a constantexpr icmp on them to see whether we know they're equal or non-equal or unsure). llvm-svn: 151093
* Check for the correct size in the invariant marker.Nick Lewycky2012-02-201-4/+7
| | | | llvm-svn: 151003
* Rename class Evaluate to Evaluator and put it in an anonymous namespace.Nick Lewycky2012-02-201-12/+17
| | | | llvm-svn: 150947
* Move EvaluateFunction and EvaluateBlock into a class, and make the class storeNick Lewycky2012-02-191-122/+137
| | | | | | the information that they pass around between them. No functionality change! llvm-svn: 150939
* Add support for invariant.start inside the static constructor evaluator. This isNick Lewycky2012-02-171-12/+47
| | | | | | | | | useful to represent a variable that is const in the source but can't be constant in the IR because of a non-trivial constructor. If globalopt evaluates the constructor, and there was an invariant.start with no matching invariant.end possible, it will mark the global constant afterwards. llvm-svn: 150794
* Handle InvokeInst in EvaluateBlock. Don't try to support exceptions, it's justNick Lewycky2012-02-121-9/+14
| | | | | | that no optz'ns have run yet to convert invokes to calls. llvm-svn: 150326
* false is totally null!Nick Lewycky2012-02-121-1/+1
| | | | llvm-svn: 150324
* Remove redundant getAnalysis<> calls in GlobalOpt. Add a few Itanium ABI callsNick Lewycky2012-02-121-10/+8
| | | | | | to TargetLibraryInfo and use one of them in GlobalOpt. llvm-svn: 150323
* Pass TargetData and TargetLibraryInfo through to the constant folder. Fixes aNick Lewycky2012-02-121-25/+37
| | | | | | few fixme's when TLI was added. llvm-svn: 150322
* Fix function name in comment to match actual name. Fix comments that are usingNick Lewycky2012-02-121-15/+15
| | | | | | doxy-style on local variables to not do so. Fix one 80-col violation. llvm-svn: 150320
* Don't traverse the PHI nodes twice. No functionality change!Nick Lewycky2012-02-121-7/+6
| | | | llvm-svn: 150319
* Tweak comment readability and grammar.Benjamin Kramer2012-02-091-2/+2
| | | | llvm-svn: 150183
* GlobalOpt: Be more aggressive about elminating side-effect free static dtors.Benjamin Kramer2012-02-091-4/+5
| | | | | | | | | GlobalOpt runs early in the pipeline (before inlining) and complex class hierarchies often introduce bitcasts or GEPs which weren't optimized away. Teach it to ignore side-effect free instructions instead of depending on other passes to remove them. llvm-svn: 150174
* [unwind removal] We no longer have 'unwind' instructions being generated, soBill Wendling2012-02-061-2/+1
| | | | | | remove the code that handles them. llvm-svn: 149901
* Split part of EvaluateFunction into a new EvaluateBlock method. No functionalityNick Lewycky2012-02-061-57/+95
| | | | | | change. llvm-svn: 149861
* Teach GlobalOpt to handle atomic accesses to globals.Nick Lewycky2012-02-051-13/+40
| | | | | | | | | | | | | | | | | | | * Most of the transforms come through intact by having each transformed load or store copy the ordering and synchronization scope of the original. * The transform that turns a global only accessed in main() into an alloca (since main is non-recursive) with a store of the initial value uses an unordered store, since it's guaranteed to be the first thing to happen in main. (Threads may have started before main (!) but they can't have the address of a function local before the point in the entry block we insert our code.) * The heap-SRoA transforms are disabled in the face of atomic operations. This can probably be improved; it seems odd to have atomic accesses to an alloca that doesn't have its address taken. AnalyzeGlobal keeps track of the strongest ordering found in any use of the global. This is more information than we need right now, but it's cheap to compute and likely to be useful. llvm-svn: 149847
* Clean up some whitespace and comments. No functionality change.Nick Lewycky2012-02-051-13/+13
| | | | llvm-svn: 149845
* SwitchInst refactoring.Stepan Dyatkovskiy2012-02-011-1/+2
| | | | | | | | | | | | | | | | | The purpose of refactoring is to hide operand roles from SwitchInst user (programmer). If you want to play with operands directly, probably you will need lower level methods than SwitchInst ones (TerminatorInst or may be User). After this patch we can reorganize SwitchInst operands and successors as we want. What was done: 1. Changed semantics of index inside the getCaseValue method: getCaseValue(0) means "get first case", not a condition. Use getCondition() if you want to resolve the condition. I propose don't mix SwitchInst case indexing with low level indexing (TI successors indexing, User's operands indexing), since it may be dangerous. 2. By the same reason findCaseValue(ConstantInt*) returns actual number of case value. 0 means first case, not default. If there is no case with given value, ErrorIndex will returned. 3. Added getCaseSuccessor method. I propose to avoid usage of TerminatorInst::getSuccessor if you want to resolve case successor BB. Use getCaseSuccessor instead, since internal SwitchInst organization of operands/successors is hidden and may be changed in any moment. 4. Added resolveSuccessorIndex and resolveCaseIndex. The main purpose of these methods is to see how case successors are really mapped in TerminatorInst. 4.1 "resolveSuccessorIndex" was created if you need to level down from SwitchInst to TerminatorInst. It returns TerminatorInst's successor index for given case successor. 4.2 "resolveCaseIndex" converts low level successors index to case index that curresponds to the given successor. Note: There are also related compatability fix patches for dragonegg, klee, llvm-gcc-4.0, llvm-gcc-4.2, safecode, clang. llvm-svn: 149481
* Add a basic-block autovectorization pass.Hal Finkel2012-02-012-1/+15
| | | | | | | This is the initial checkin of the basic-block autovectorization pass along with some supporting vectorization infrastructure. Special thanks to everyone who helped review this code over the last several months (especially Tobias Grosser). llvm-svn: 149468
* continue making the world safe for ConstantDataVector. At this point,Chris Lattner2012-01-271-1/+1
| | | | | | | we should (theoretically optimize and codegen ConstantDataVector as well as ConstantVector. llvm-svn: 149116
* Continue improving support for ConstantDataAggregate, and use theChris Lattner2012-01-261-28/+5
| | | | | | new methods recently added to (sometimes greatly!) simplify code. llvm-svn: 149024
* use Constant::getAggregateElement to simplify a bunch of code.Chris Lattner2012-01-251-36/+2
| | | | llvm-svn: 148934
* More dead code removal (using -Wunreachable-code)David Blaikie2012-01-201-1/+0
| | | | llvm-svn: 148578
* Add a new PassManagerBuilder customization point,Dan Gohman2012-01-171-0/+2
| | | | | | | EP_ModuleOptimizerEarly, to allow passes to be added before the main ModulePass optimizers. llvm-svn: 148329
* Re-fix the issue Bill fixed in r147899 in a slightly different way, which ↵Eli Friedman2012-01-111-5/+7
| | | | | | doesn't abuse the semantics of linker_private. We don't really want to merge any string constant with a weak_odr global. llvm-svn: 147971
* If the global variable is removed by the linker, then don't constant merge itBill Wendling2012-01-111-6/+10
| | | | | | | | | | | | | | with other symbols. An object in the __cfstring section is suppoed to be filled with CFString objects, which have a pointer to ___CFConstantStringClassReference followed by a pointer to a __cstring. If we allow the object in the __cstring section to be merged with another global, then it could end up in any section. Because the linker is going to remove these symbols in the final executable, we shouldn't bother to merge them. <rdar://problem/10564621> llvm-svn: 147899
* PR11705, part 2: globalopt shouldn't put inttoptr/ptrtoint operations into ↵Eli Friedman2012-01-051-10/+20
| | | | | | global initializers if there's an implied extension or truncation. llvm-svn: 147625
* SCCCaptured is trivially false on entry to this loop and not modified inside it.Nick Lewycky2012-01-051-1/+1
| | | | | | Eliminate the dead test for it on each loop iteration. No functionality change. llvm-svn: 147616
* Change CaptureTracking to pass a Use* instead of a Value* when a value isNick Lewycky2011-12-281-5/+222
| | | | | | | | | | | | | | captured. This allows the tracker to look at the specific use, which may be especially interesting for function calls. Use this to fix 'nocapture' deduction in FunctionAttrs. The existing one does not iterate until a fixpoint and does not guarantee that it produces the same result regardless of iteration order. The new implementation builds up a graph of how arguments are passed from function to function, and uses a bottom-up walk on the argument-SCCs to assign nocapture. This gets us nocapture more often, and does so rather efficiently and independent of iteration order. llvm-svn: 147327
* LLVMBuild: Remove trailing newline, which irked me.Daniel Dunbar2011-12-121-1/+0
| | | | llvm-svn: 146409
* Remove unused include.Duncan Sands2011-12-071-1/+0
| | | | llvm-svn: 146037
* Fix a few more places where TargetData/TargetLibraryInfo is not being passed.Chad Rosier2011-12-021-2/+5
| | | | | | Add FIXMEs to places that are non-trivial to fix. llvm-svn: 145661
* Last bit of TargetLibraryInfo propagation. Also fixed a case for TargetDataChad Rosier2011-12-011-9/+17
| | | | | | | where it appeared beneficial to pass. More of rdar://10500969 llvm-svn: 145630
* make asan work at -O0, llvm part. Patch by glider@google.comKostya Serebryany2011-11-301-1/+1
| | | | llvm-svn: 145530
* build/CMake: Finish removal of add_llvm_library_dependencies.Daniel Dunbar2011-11-291-11/+0
| | | | llvm-svn: 145420
* Remove all remaining uses of Value::getNameStr().Benjamin Kramer2011-11-151-1/+1
| | | | llvm-svn: 144648
* build: Attempt to rectify inconsistencies between CMake and LLVMBuild ↵Daniel Dunbar2011-11-121-0/+1
| | | | | | | | versions of explicit dependencies. - The hope is that we have a tool/test to verify these are accurate (and tight) soon. llvm-svn: 144444
* LLVMBuild: Alphabetize required_libraries lists.Daniel Dunbar2011-11-111-1/+1
| | | | llvm-svn: 144416
* build: Add initial cut at LLVMBuild.txt files.Daniel Dunbar2011-11-031-0/+24
| | | | llvm-svn: 143634
* Refactor code from inlining and globalopt that checks whether a function ↵Eli Friedman2011-10-202-5/+2
| | | | | | definition is unused, and enhance it so it can tell that functions which are only used by a blockaddress are in fact dead. This probably doesn't happen much on most code, but the Linux kernel's _THIS_IP_ can trigger this issue with blockaddress. (GlobalDCE can also handle the given tescase, but we only run that at -O3.) Found while looking at PR11180. llvm-svn: 142572
* Inlining and unrolling heuristics should be aware of free truncs.Andrew Trick2011-10-012-0/+5
| | | | | | | | | | We want heuristics to be based on accurate data, but more importantly we don't want llvm to behave randomly. A benign trunc inserted by an upstream pass should not cause a wild swings in optimization level. See PR11034. It's a general problem with threshold-based heuristics, but we can make it less bad. llvm-svn: 140919
* whitespaceAndrew Trick2011-10-012-18/+18
| | | | llvm-svn: 140916
* Stop emitting instructions with the name "tmp" they eat up memory and have ↵Benjamin Kramer2011-09-271-2/+1
| | | | | | | | to be uniqued, without any benefit. If someone prefers %tmp42 to %42, run instnamer. llvm-svn: 140634
* Place the check for an exit landing pad where it will be run on both code ↵Bill Wendling2011-09-201-6/+15
| | | | | | paths through the if-then-else. llvm-svn: 140195
* Omit extracting a loop if one of the exits is a landing pad.Bill Wendling2011-09-201-5/+11
| | | | | | | | | The landing pad must accompany the invoke when it's extracted. However, if it does, then the loop isn't properly extracted. I.e., the resulting extraction has a loop in it. The extracted function is then extracted, etc. resulting in an infinite loop. llvm-svn: 140193
* Check the terminator, not the basic block.Bill Wendling2011-09-201-1/+2
| | | | llvm-svn: 140176
* When extracting a basic block that ends in an 'invoke' instruction, we need toBill Wendling2011-09-201-7/+46
| | | | | | | | | | extract its associated landing pad block as well. However, that landing pad block may have more than one predecessor. So split the landing pad block so that individual landing pads have only one predecessor. This type of transformation may produce a false positive with bugpoint. llvm-svn: 140173
* C API functions must be able to see their extern "C" definitions, or it will ↵Benjamin Kramer2011-08-191-0/+1
| | | | | | be impossible to call them from C. llvm-svn: 138022
* Add a mechanism for optimisation plugins to register passes that all front ↵David Chisnall2011-08-161-0/+15
| | | | | | | | ends can use without needing to be aware of the plugin (or the plugin be aware of the front end). Before 3.0, I'd like to add a mechanism for automatically loading a set of plugins from a config file. API suggestions welcome... llvm-svn: 137717
* Revert a bit of r137667; the logic in question can safely handle atomic ↵Eli Friedman2011-08-161-4/+4
| | | | | | load/store. llvm-svn: 137702
OpenPOWER on IntegriCloud