summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Scalar/SCCP.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [SCCP] Remove code in visitBinaryOperator (and add tests).Davide Italiano2016-11-221-11/+3
| | | | | | | | | | We visit and/or, we try to derive a lattice value for the instruction even if one of the operands is overdefined. If the non-overdefined value is still 'unknown' just return and wait for ResolvedUndefsIn to "plug in" the correct value. This simplifies the logic a bit. While I'm here add tests for missing cases. llvm-svn: 287709
* [SCCP] Don't delete side-effecting instructionsSanjoy Das2016-08-241-17/+6
| | | | | | | | I'm not sure if the `!isa<CallInst>(Inst) && !isa<TerminatorInst>(Inst))` bit is correct either, but this fixes the case we know is broken. llvm-svn: 279647
* Use range algorithms instead of unpacking begin/endDavid Majnemer2016-08-111-2/+1
| | | | | | No functionality change is intended. llvm-svn: 278417
* Consistently use ModuleAnalysisManagerSean Silva2016-08-091-1/+1
| | | | | | | | | | | Besides a general consistently benefit, the extra layer of indirection allows the mechanical part of https://reviews.llvm.org/D23256 that requires touching every transformation and analysis to be factored out cleanly. Thanks to David for the suggestion. llvm-svn: 278078
* Consistently use FunctionAnalysisManagerSean Silva2016-08-091-1/+1
| | | | | | | | | | | Besides a general consistently benefit, the extra layer of indirection allows the mechanical part of https://reviews.llvm.org/D23256 that requires touching every transformation and analysis to be factored out cleanly. Thanks to David for the suggestion. llvm-svn: 278077
* [SCCP] Zap multiple return values.Davide Italiano2016-07-201-9/+41
| | | | | | | | | We can replace the return values with undef if we replaced all the call uses with a constant/undef. Differential Revision: https://reviews.llvm.org/D22336 llvm-svn: 276174
* [SCCP] Improve assert messages. NFCI.Davide Italiano2016-07-191-4/+6
| | | | | | | I've been hitting those already while working on SCCP and I think it's be useful to provide a more explanatory diagnostic. llvm-svn: 276007
* [SCCP] Merge two conditions into one. NFCI.Davide Italiano2016-07-151-3/+1
| | | | llvm-svn: 275593
* [SCCP] Pass the Solver by reference, copies are expensive ...Davide Italiano2016-07-141-2/+2
| | | | | | | | .. enough to cause LTO compile time to regress insanely. Thanks *a lot* to Rafael for reporting the problem and testing the fix! llvm-svn: 275468
* [SCCP] Pass a Value * instead of templating this function. NFC.Davide Italiano2016-07-141-9/+8
| | | | | | Thanks to Eli for the suggestion! llvm-svn: 275366
* [IPSCCP] Constant fold struct argument/instructions when all the lattice ↵Davide Italiano2016-07-141-10/+3
| | | | | | | | | | | values are constant. This now should also work with the interprocedural variant of the pass. Slightly easier now that the yak is shaved. Differential Revision: http://reviews.llvm.org/D22329 llvm-svn: 275363
* [SCCP] Generalize tryToReplaceInstWithConstant to work also with arguments.Davide Italiano2016-07-141-22/+18
| | | | llvm-svn: 275357
* [SCCP] Have the logic for replacing insts with constant in a single place.Davide Italiano2016-07-131-53/+50
| | | | | | | | | The code was pretty much copy-pasted between SCCP and IPSCCP. The situation became clearly worse after I introduced the support for folding structs in SCCP. This commit is NFC as we currently (still) skip the replacement step in IPSCCP, but I'll change this soon. llvm-svn: 275339
* [SCCP] Factor out common code.Davide Italiano2016-07-131-8/+9
| | | | llvm-svn: 275308
* [SCCP] Use early return. NFCI.Davide Italiano2016-07-131-5/+5
| | | | llvm-svn: 275307
* [SCCP] Constant fold structs if all the lattice value are constant.Davide Italiano2016-07-121-9/+35
| | | | | | Differential Revision: http://reviews.llvm.org/D22269 llvm-svn: 275208
* [SCCP] Try to follow the DRY principle, use `OpSt`.Davide Italiano2016-07-111-3/+2
| | | | | | Thanks to Eli Friedman for pointing out in his post-commit review! llvm-svn: 275084
* [SCCP] Rename undefined -> unknown.Davide Italiano2016-07-101-40/+40
| | | | | | | | | | In the solver, isUndefined() does really mean "we don't know the value yet" rather than "this is an UndefinedValue". Discussed with Eli Friedman. Differential Revision: http://reviews.llvm.org/D22192 llvm-svn: 275004
* [SCCP] Remove wrong and misleading vector handling code.Davide Italiano2016-07-091-53/+0
| | | | | | | | | This code was already commented out and it made some weird assumptions, e.g. using isUndefined() as "this value is UndefValue" instead of "we haven't computed this value is yet". Thanks to Eli Friedman for pointing out where I was wrong (and where this code was wrong). llvm-svn: 274995
* [SCCP] Fold constants as we build them whne visiting cast instructions.Davide Italiano2016-07-081-2/+4
| | | | | | | | | This should be slightly more efficient and could avoid spurious overdefined markings, as Eli pointed out. Differential Revision: http://reviews.llvm.org/D22122 llvm-svn: 274905
* Apply clang-tidy's modernize-loop-convert to most of lib/Transforms.Benjamin Kramer2016-06-261-27/+26
| | | | | | Only minor manual fixes. No functionality change intended. llvm-svn: 273808
* Revert "[SimplifyCFG] Stop inserting calls to llvm.trap for UB"David Majnemer2016-06-251-1/+2
| | | | | | This reverts commit r273778, it seems to break UBSan :/ llvm-svn: 273779
* [SimplifyCFG] Stop inserting calls to llvm.trap for UBDavid Majnemer2016-06-251-2/+1
| | | | | | | | | | | | | | | | | SimplifyCFG had logic to insert calls to llvm.trap for two very particular IR patterns: stores and invokes of undef/null. While InstCombine canonicalizes certain undefined behavior IR patterns to stores of undef, phase ordering means that this cannot be relied upon in general. There are much better tools than llvm.trap: UBSan and ASan. N.B. I could be argued into reverting this change if a clear argument as to why it is important that we synthesize llvm.trap for stores, I'd be hard pressed to see why it'd be useful for invokes... llvm-svn: 273778
* [SCCP] Don't assume all Constants are ConstantIntDavid Majnemer2016-06-231-8/+8
| | | | | | This fixes PR28269. llvm-svn: 273521
* [PM] SCCP should preserve GlobalsAA even if the IR is mutated.Davide Italiano2016-05-291-1/+4
| | | | llvm-svn: 271149
* [SCCP] Prefer class to struct.Davide Italiano2016-05-191-2/+4
| | | | llvm-svn: 270074
* [PM] Port per-function SCCP to the new pass manager.Davide Italiano2016-05-181-44/+52
| | | | llvm-svn: 269937
* [PM/SCCP] Fix pass dependencies.Davide Italiano2016-05-151-1/+4
| | | | | | | | | | | | TargetLibraryInfoWrapperPass is a dependency of SCCP but it's not listed as such. Chandler pointed out this is an easy mistake to make which only surfaces in weird crashes with some flag combinations. This code will go away anyway at some point in the future, but as long as it's (still) exercised, try to make it correct. llvm-svn: 269589
* [SCCP] Use range-based for loops. NFC.Davide Italiano2016-05-141-10/+10
| | | | llvm-svn: 269578
* [SCCP] Resolve shifts beyond the bitwidth to undefDavid Majnemer2016-05-121-0/+16
| | | | | | | | | Shifts beyond the bitwidth are undef but SCCP resolved them to zero. Instead, DTRT and resolve them to undef. This reimplements the transform which caused PR27712. llvm-svn: 269269
* Revert "[SCCP] Partially propagate informations when the input is not fully ↵Davide Italiano2016-05-111-3/+0
| | | | | | | | defined." This reverts commit r269105 as it caused PR27712. llvm-svn: 269252
* [SCCP] Partially propagate informations when the input is not fully defined.Davide Italiano2016-05-101-0/+3
| | | | | | | | | | With this patch: %r1 = lshr i64 -1, 4294967296 -> undef Before this patch: %r1 = lshr i64 -1, 4294967296 -> 0 llvm-svn: 269105
* [PM] Port Interprocedural SCCP to the new pass manager.Davide Italiano2016-05-051-42/+53
| | | | llvm-svn: 268684
* Revert "[SCCP] Throw away dead code. NFC."Davide Italiano2016-05-041-0/+3
| | | | | | This reverts commit r268568, as it broke the bots. llvm-svn: 268570
* [SCCP] Throw away dead code. NFC.Davide Italiano2016-05-041-3/+0
| | | | llvm-svn: 268568
* Re-commit optimization bisect support (r267022) without new pass manager ↵Andrew Kaylor2016-04-221-1/+4
| | | | | | | | | | support. The original commit was reverted because of a buildbot problem with LazyCallGraph::SCC handling (not related to the OptBisect handling). Differential Revision: http://reviews.llvm.org/D19172 llvm-svn: 267231
* Revert "Initial implementation of optimization bisect support."Vedant Kumar2016-04-221-4/+1
| | | | | | | | This reverts commit r267022, due to an ASan failure: http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check/1549 llvm-svn: 267115
* Initial implementation of optimization bisect support.Andrew Kaylor2016-04-211-1/+4
| | | | | | | | | | | | This patch implements a optimization bisect feature, which will allow optimizations to be selectively disabled at compile time in order to track down test failures that are caused by incorrect optimizations. The bisection is enabled using a new command line option (-opt-bisect-limit). Individual passes that may be skipped call the OptBisect object (via an LLVMContext) to see if they should be skipped based on the bisect limit. A finer level of control (disabling individual transformations) can be managed through an addition OptBisect method, but this is not yet used. The skip checking in this implementation is based on (and replaces) the skipOptnoneFunction check. Where that check was being called, a new call has been inserted in its place which checks the bisect limit and the optnone attribute. A new function call has been added for module and SCC passes that behaves in a similar way. Differential Revision: http://reviews.llvm.org/D19172 llvm-svn: 267022
* Don't IPO over functions that can be de-refinedSanjoy Das2016-04-081-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Fixes PR26774. If you're aware of the issue, feel free to skip the "Motivation" section and jump directly to "This patch". Motivation: I define "refinement" as discarding behaviors from a program that the optimizer has license to discard. So transforming: ``` void f(unsigned x) { unsigned t = 5 / x; (void)t; } ``` to ``` void f(unsigned x) { } ``` is refinement, since the behavior went from "if x == 0 then undefined else nothing" to "nothing" (the optimizer has license to discard undefined behavior). Refinement is a fundamental aspect of many mid-level optimizations done by LLVM. For instance, transforming `x == (x + 1)` to `false` also involves refinement since the expression's value went from "if x is `undef` then { `true` or `false` } else { `false` }" to "`false`" (by definition, the optimizer has license to fold `undef` to any non-`undef` value). Unfortunately, refinement implies that the optimizer cannot assume that the implementation of a function it can see has all of the behavior an unoptimized or a differently optimized version of the same function can have. This is a problem for functions with comdat linkage, where a function can be replaced by an unoptimized or a differently optimized version of the same source level function. For instance, FunctionAttrs cannot assume a comdat function is actually `readnone` even if it does not have any loads or stores in it; since there may have been loads and stores in the "original function" that were refined out in the currently visible variant, and at the link step the linker may in fact choose an implementation with a load or a store. As an example, consider a function that does two atomic loads from the same memory location, and writes to memory only if the two values are not equal. The optimizer is allowed to refine this function by first CSE'ing the two loads, and the folding the comparision to always report that the two values are equal. Such a refined variant will look like it is `readonly`. However, the unoptimized version of the function can still write to memory (since the two loads //can// result in different values), and selecting the unoptimized version at link time will retroactively invalidate transforms we may have done under the assumption that the function does not write to memory. Note: this is not just a problem with atomics or with linking differently optimized object files. See PR26774 for more realistic examples that involved neither. This patch: This change introduces a new set of linkage types, predicated as `GlobalValue::mayBeDerefined` that returns true if the linkage type allows a function to be replaced by a differently optimized variant at link time. It then changes a set of IPO passes to bail out if they see such a function. Reviewers: chandlerc, hfinkel, dexonsmith, joker.eph, rnk Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D18634 llvm-svn: 265762
* Fix build bot breakageDavid Majnemer2016-01-241-1/+1
| | | | llvm-svn: 258661
* Fix buildbot failuresDavid Majnemer2016-01-241-1/+1
| | | | llvm-svn: 258655
* [SCCP] Remove duplicate codeDavid Majnemer2016-01-241-20/+11
| | | | | | | | | SCCP has code identical to changeToUnreachable's behavior, switch it over to just call changeToUnreachable. No functionality change intended. llvm-svn: 258654
* [InstCombine, SCCP] Consolidate code used to remove instructionsDavid Majnemer2016-01-241-19/+2
| | | | | | | | | InstCombine and SCCP both want to remove dead code in a very particular way but using identical means to do so. Share the code between the two. No functionality change is intended. llvm-svn: 258653
* [opaque pointer types] [NFC] Add an explicit type argument to ↵Eduard Burtescu2016-01-221-1/+1
| | | | | | | | | | | | ConstantFoldLoadFromConstPtr. Reviewers: mjacob, dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16418 llvm-svn: 258472
* GlobalValue: use getValueType() instead of getType()->getPointerElementType().Manuel Jacob2016-01-161-1/+1
| | | | | | | | | | | | Reviewers: mjacob Subscribers: jholewinski, arsenm, dsanders, dblaikie Patch by Eduard Burtescu. Differential Revision: http://reviews.llvm.org/D16260 llvm-svn: 257999
* [SCCP] Don't violate the lattice invariantsDavid Majnemer2016-01-071-15/+42
| | | | | | | | | | We marked values which are 'undef' as constant instead of undefined which violates SCCP's invariants. If we can figure out that a computation results in 'undef', leave it in the undefined state. This fixes PR16052. llvm-svn: 257102
* Remove junk accidentally commited with r257087David Majnemer2016-01-071-1/+1
| | | | llvm-svn: 257089
* [SCCP] Can't go from overdefined to constantDavid Majnemer2016-01-071-3/+3
| | | | | | | | The fix for PR23999 made us mark loads of null as producing the constant undef which upsets the lattice. Instead, keep the load as "undefined". This fixes PR26044. llvm-svn: 257087
* [IR] Reformulate LLVM's EH funclet IRDavid Majnemer2015-12-121-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
* [SCCP] More informative message if we don't know how to handle a terminator.Davide Italiano2015-11-251-1/+1
| | | | llvm-svn: 254093
OpenPOWER on IntegriCloud