summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Utils
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert "ValueMapper: Treat LocalAsMetadata more like function-local Values"Duncan P. N. Exon Smith2016-04-081-60/+23
| | | | | | | | | | | | | This reverts commit r265759, since even this limited version breaks some bots: http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/3311 http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/17696 This also reverts r265761 "ValueMapper: Unduplicate RF_NoModuleLevelChanges check, NFC", since I had trouble separating it from r265759. llvm-svn: 265765
* Don't IPO over functions that can be de-refinedSanjoy Das2016-04-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* ValueMapper: Unduplicate RF_NoModuleLevelChanges check, NFCDuncan P. N. Exon Smith2016-04-081-8/+5
| | | | llvm-svn: 265761
* ValueMapper: Treat LocalAsMetadata more like function-local ValuesDuncan P. N. Exon Smith2016-04-081-16/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a partial re-commit -- maybe more of a re-implementation -- of r265631 (reverted in r265637). This makes RF_IgnoreMissingLocals behave (almost) consistently between the Value and the Metadata hierarchy. In particular: - MapValue returns nullptr or "metadata !{}" for missing locals in MetadataAsValue/LocalAsMetadata bridging paris, depending on the RF_IgnoreMissingLocals flag. - MapValue doesn't memoize LocalAsMetadata-related results. - MapMetadata no longer deals with LocalAsMetadata or RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but I realized during testing it would make the patch simpler with no loss of generality.) r265631 went too far, making both functions universally ignore RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt. Reassociate (and possibly other passes) don't currently maintain dominates-use invariants for metadata operands, resulting in IR like this: define void @foo(i32 %arg) { call void @llvm.some.intrinsic(metadata i32 %x) %x = add i32 1, i32 %arg } If the inliner chooses to inline @foo into another function, then RemapInstruction will call `MapValue(metadata i32 %x)` and assert that the return is not nullptr. I've filed PR27273 to add a Verifier check and fix the underlying problem in the optimization passes. As a workaround, return `!{}` instead of nullptr for unmapped LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match the behaviour of r265631. Original commit message: ValueMapper: Make LocalAsMetadata match function-local Values Start treating LocalAsMetadata similarly to function-local members of the Value hierarchy in MapValue and MapMetadata. - Don't memoize them. - Return nullptr if they are missing. This also cleans up ConstantAsMetadata to stop listening to the RF_IgnoreMissingLocals flag. llvm-svn: 265759
* Revert "ValueMapper: Make LocalAsMetadata match function-local Values"Duncan P. N. Exon Smith2016-04-071-38/+16
| | | | | | | | | | | This reverts commit r265631, since it caused bot failures: http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/3256 http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/7272 Looks like something is depending on the old behaviour. I'll try to track it down and recommit. llvm-svn: 265637
* ValueMapper: Allow RF_IgnoreMissingLocals and RF_NullMapMissingGlobalValuesDuncan P. N. Exon Smith2016-04-071-7/+1
| | | | | | | | | Remove the assertion that disallowed the combination, since RF_IgnoreMissingLocals should have no effect on globals. As it happens, RF_NullMapMissingGlobalValues asserted in MapValue(Constant*,...), so I also changed a cast to a cast_or_null to get my test passing. llvm-svn: 265633
* ValueMapper: Make LocalAsMetadata match function-local ValuesDuncan P. N. Exon Smith2016-04-071-16/+38
| | | | | | | | | | | | | Start treating LocalAsMetadata similarly to function-local members of the Value hierarchy in MapValue and MapMetadata. - Don't memoize them. - Return nullptr if they are missing. This also cleans up ConstantAsMetadata to stop listening to the RF_IgnoreMissingLocals flag. llvm-svn: 265631
* IR: RF_IgnoreMissingValues => RF_IgnoreMissingLocals, NFCDuncan P. N. Exon Smith2016-04-074-10/+20
| | | | | | | | | | | | | | | | | | | | | | | Clarify what this RemapFlag actually means. - Change the flag name to match its intended behaviour. - Clearly document that it's not supposed to affect globals. - Add a host of FIXMEs to indicate how to fix the behaviour to match the intent of the flag. RF_IgnoreMissingLocals should only affect the behaviour of RemapInstruction for function-local operands; namely, for operands of type Argument, Instruction, and BasicBlock. Currently, it is *only* passed into RemapInstruction calls (and the transitive MapValue calls that it makes). When I split Metadata from Value I didn't understand the flag, and I used it in a bunch of places for "global" metadata. This commit doesn't have any functionality change, but prepares to cleanup MapMetadata and MapValue. llvm-svn: 265628
* Follow-up for r265605: don't mutate vector we're iterating.Michael Zolotukhin2016-04-071-4/+6
| | | | llvm-svn: 265625
* [LoopUnroll] Fix the way we update DT after complete unrolling.Michael Zolotukhin2016-04-061-10/+15
| | | | | | | | Updating dominators for exit-blocks of the unrolled loops is not enough, as shown in PR27157. The proper way is to update dominators for all dominance-children of original loop blocks. llvm-svn: 265605
* NFC: make AtomicOrdering an enum classJF Bastien2016-04-061-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In the context of http://wg21.link/lwg2445 C++ uses the concept of 'stronger' ordering but doesn't define it properly. This should be fixed in C++17 barring a small question that's still open. The code currently plays fast and loose with the AtomicOrdering enum. Using an enum class is one step towards tightening things. I later also want to tighten related enums, such as clang's AtomicOrderingKind (which should be shared with LLVM as a 'C++ ABI' enum). This change touches a few lines of code which can be improved later, I'd like to keep it as NFC for now as it's already quite complex. I have related changes for clang. As a follow-up I'll add: bool operator<(AtomicOrdering, AtomicOrdering) = delete; bool operator>(AtomicOrdering, AtomicOrdering) = delete; bool operator<=(AtomicOrdering, AtomicOrdering) = delete; bool operator>=(AtomicOrdering, AtomicOrdering) = delete; This is separate so that clang and LLVM changes don't need to be in sync. Reviewers: jyknight, reames Subscribers: jyknight, llvm-commits Differential Revision: http://reviews.llvm.org/D18775 llvm-svn: 265602
* ValueMapper: Fix delayed blockaddress handling after r265273Duncan P. N. Exon Smith2016-04-061-3/+3
| | | | | | | | | r265273 added Mapper::mapBlockAddress, which delays mapping a blockaddress value until the function has a body. The condition was backwards, and should be checking Function::empty instead of GlobalValue::isDeclaration. llvm-svn: 265508
* Try harder to appease MSVC after r265456Duncan P. N. Exon Smith2016-04-051-3/+12
| | | | | | r265465 wasn't good enough. I need to spell out all the moves. llvm-svn: 265470
* IR: Introduce ConstantAggregate, NFCDuncan P. N. Exon Smith2016-04-051-2/+1
| | | | | | | | | | | | Add a common parent class for ConstantArray, ConstantVector, and ConstantStruct called ConstantAggregate. These are the aggregate subclasses of Constant that take operands. This is mainly a cleanup, adding common `isa` target and removing duplicated code. However, it also simplifies caching which constants point transitively at `GlobalValue` (a possible future direction). llvm-svn: 265466
* Try to appease MSVC after r265456Duncan P. N. Exon Smith2016-04-051-0/+4
| | | | | | | I can't remember if adding `= default` will make MSVC happy, or if I have to spell this out. Let's try the cleaner version first. llvm-svn: 265465
* ValueMapper: Rewrite Mapper::mapMetadata without recursionDuncan P. N. Exon Smith2016-04-051-108/+329
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit completely rewrites Mapper::mapMetadata (the implementation of llvm::MapMetadata) using an iterative algorithm. The guts of the new algorithm are in MDNodeMapper::map, the entry function in a new class. Previously, Mapper::mapMetadata performed a recursive exploration of the graph with eager "just in case there's a reason" malloc traffic. The new algorithm has these benefits: - New nodes and temporaries are not created eagerly. - Uniquing cycles are not duplicated (see new unit test). - No recursion. Given a node to map, it does this: 1. Use a worklist to perform a post-order traversal of the transitively referenced unmapped nodes. 2. Track which nodes will change operands, and which will have new addresses in the mapped scheme. Propagate the changes through the POT until fixed point, to pick up uniquing cycles that need to change. 3. Map all the distinct nodes without touching their operands. If RF_MoveDistinctMetadata, they get mapped to themselves; otherwise, they get mapped to clones. 4. Map the uniqued nodes (bottom-up), lazily creating temporaries for forward references as needed. 5. Remap the operands of the distinct nodes. Mehdi helped me out by profiling this with -flto=thin. On his workload (importing/etc. for opt.cpp), MapMetadata sped up by 15%, contributed about 50% less to persistent memory, and made about 100x fewer calls to malloc. The speedup is less than I'd hoped. The profile mainly blames DenseMap lookups; perhaps there's a way to reduce them (e.g., by disallowing remapping of MDString). It would be nice to break the strange remaining recursion on the Value side: MapValue => materializeInitFor => RemapInstruction => MapValue. I think we could do this by having materializeInitFor return a worklist of things to be remapped. llvm-svn: 265456
* Adds the ability to use an epilog remainder loop during loop unrolling and makesDavid L Kreitzer2016-04-052-78/+336
| | | | | | | | | | this the default behavior. Patch by Evgeny Stupachenko (evstupac@gmail.com). Differential Revision: http://reviews.llvm.org/D18158 llvm-svn: 265388
* ValueMapper: Remove old FIXMEs; almost NFCDuncan P. N. Exon Smith2016-04-041-21/+1
| | | | | | | | | | | | | | | | | | | | | Remove a few old FIXMEs from the original commit of the Metadata/Value split in r223802. These are commented out assertions to the effect that calls between mapValue and mapMetadata never return nullptr. (The only behaviour change is that Mapper::mapSimpleMetadata memoizes the nullptr return.) When I originally rewrote the mapping code, I thought we could be stricter in the new metadata hierarchy and never return nullptr when RF_NullMapMissingGlobalValues was off. It's still not entirely clear to me why these assertions failed (a few months ago, I had a theory that I forgot to write down, but that's helping no one). Understood or not, I no longer see how these commented-out assertions would be useful. I'm relegating them to the annals of source control before making significant changes to ValueMapper.cpp. llvm-svn: 265282
* ValueMapper: Disallow metadata mapping recursion through mapValueDuncan P. N. Exon Smith2016-04-031-0/+5
| | | | | | | | | | | | | | | This adds an assertion to maintain the property from r265273. When Mapper::mapSimpleMetadata calls Mapper::mapValue, it should not find its way back to mapMetadataImpl. This guarantees that mapSimpleMetadata is not involved in any recursion. Since Mapper::mapValue calls out to arbitrary materializers, we need to save a bit on the ValueMap to make this assertion effective. There should be no functionality change here. This co-recursion should already have been impossible. llvm-svn: 265276
* Work around MSVC failure from r265273Duncan P. N. Exon Smith2016-04-031-0/+10
| | | | | | http://lab.llvm.org:8011/builders/sanitizer-windows/builds/19726 llvm-svn: 265275
* ValueMapper: Avoid recursion in mapSimplifiedMetadata, NFCDuncan P. N. Exon Smith2016-04-031-9/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | The main change is to delay materializing GlobalValue initializers from Mapper::mapValue until Mapper::~Mapper. This effectively removes all recursion from mapSimplifiedMetadata, as promised in r265270. mapSimplifiedMetadata calls mapValue for ConstantAsMetadata nodes to find the mapped constant, and now it shouldn't be possible for mapValue to indirectly re-invoke mapMetadata. I'll add an assertion to that effect in a follow-up (separated so that the assertion can easily be reverted independently, if it comes to that). This a step toward a broader goal: converting Mapper::mapMetadataImpl from a recursive to an iterative algorithm. When a BlockAddress points at a BasicBlock inside an unmaterialized function body, we need to delay it until the function body is materialized in Mapper::~Mapper. This commit creates a temporary BasicBlock and returns a new BlockAddress, then RAUWs the BasicBlock once it is known. This situation should be extremely rare since a BlockAddress is usually used from within the function it's referencing (and BlockAddress itself is rare). There should be no observable functionality change. llvm-svn: 265273
* ValueMapper: Split out mapSimpleMetadata, NFCDuncan P. N. Exon Smith2016-04-031-4/+13
| | | | | | | | | | | | | | | | | | | | Split out a helper for mapping metadata without operands. This is any metadata that is not an MDNode, and any MDNode where the answer is known without looking at operands. Through some weird twists, this function is co-recursive: mapSimpleMetadata => MapValue => materializeInitFor => linkFunctionBody => RemapInstructions => MapMetadata => mapSimpleMetadata I plan to break the recursion in a follow-up. llvm-svn: 265270
* ValueMapper: Introduce Mapper helper class, NFCDuncan P. N. Exon Smith2016-04-031-85/+101
| | | | | | | Remove a bunch of boilerplate from ValueMapper.cpp by using a new file-local class called Mapper. llvm-svn: 265268
* [SimplifyLibCalls] Garbage collect dead code.Davide Italiano2016-04-031-28/+7
| | | | | | | | | | We already skip optimizations if the return value of printf() is used, so CI->use_empty() is always true. Differential Revision: http://reviews.llvm.org/D18656 llvm-svn: 265253
* Linker: Remove IRMover::isMetadataUnneeded indirection; almost NFCDuncan P. N. Exon Smith2016-04-021-3/+0
| | | | | | | | | | | | | | | | Instead of checking live during MapMetadata whether a subprogram is needed, seed the ValueMap with `nullptr` up-front. There is a small hypothetical functionality change. Previously, calling MapMetadataOp on a node whose "scope:" chain led to an unneeded subprogram would return nullptr. However, if that were ever called, then the subprogram would be needed; a situation that the IRMover is supposed to avoid a priori! Besides cleaning up the code a little, this restores a nice property: MapMetadataOp returns the same as MapMetadata. llvm-svn: 265229
* ValueMapper: Add support for seeding metadata with nullptrDuncan P. N. Exon Smith2016-04-021-4/+4
| | | | | | | | | | | | | Support seeding a ValueMap with nullptr for Metadata entries, a situation I didn't consider in the Metadata/Value split. I added a ValueMapper::getMappedMD accessor that returns an Optional<Metadata*> with the mapped (possibly null) metadata. IRMover needs to use this to avoid modifying the map when it's checking for unneeded subprograms. I updated a call from bugpoint since I find the new code clearer. llvm-svn: 265228
* Fix "warning: variabl 'XX’ set but not used" in release build (variable ↵Mehdi Amini2016-04-021-1/+1
| | | | | | | used in assertion, NFC) From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265220
* Don't insert stackrestore on deoptimizing returnsSanjoy Das2016-04-011-2/+4
| | | | | | | | They're not necessary (since the stack pointer is trivially restored on return), and the way LLVM inserts the stackrestore calls breaks the IR (we get a stackrestore between the deoptimize call and the return). llvm-svn: 265101
* Don't insert lifetime end markers on deoptimizing returnsSanjoy Das2016-04-011-2/+5
| | | | | | | | | They're not necessary (since the lifetime of the alloca is trivially over due to the return), and the way LLVM inserts the lifetime.end markers breaks the IR (we get a lifetime end marker between the deoptimize call and the return). llvm-svn: 265100
* Preserve blockaddress use edges in the module splitter.Evgeniy Stepanov2016-03-311-45/+46
| | | | | | | | "blockaddress" can not apply to an external function. All blockaddress constant uses must belong to the same module as the definition of the target function. llvm-svn: 265061
* Preserve extern_weak linkage in CloneModule.Evgeniy Stepanov2016-03-311-10/+15
| | | | | | | Only force "extern" linkage if the function used to be a definition in the source module. Declarations keep their original linkage. llvm-svn: 265043
* Introduce a @llvm.experimental.guard intrinsicSanjoy Das2016-03-311-5/+7
| | | | | | | | | | | | | | | | | | | | | | | Summary: As discussed on llvm-dev[1]. This change adds the basic boilerplate code around having this intrinsic in LLVM: - Changes in Intrinsics.td, and the IR Verifier - A lowering pass to lower @llvm.experimental.guard to normal control flow - Inliner support [1]: http://lists.llvm.org/pipermail/llvm-dev/2016-February/095523.html Reviewers: reames, atrick, chandlerc, rnk, JosephTremoulet, echristo Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D18527 llvm-svn: 264976
* Cloning: Reduce complexity of debug info cloning and fix correctness issue.Peter Collingbourne2016-03-302-3/+11
| | | | | | | | | | | | | Commit r260791 contained an error in that it would introduce a cross-module reference in the old module. It also introduced O(N^2) complexity in the module cloner by requiring the entire module to be visited for each function. Fix both of these problems by avoiding use of the CloneDebugInfoMetadata function (which is only designed to do intra-module cloning) and cloning function-attached metadata in the same way that we clone all other metadata. Differential Revision: http://reviews.llvm.org/D18583 llvm-svn: 264935
* Remove HasFnAttribute guards to getFnAttribute callsNirav Dave2016-03-301-4/+2
| | | | | | | | | | | | These checks are redundant and can be removed Reviewers: hans Subscribers: llvm-commits, mzolotukhin Differential Revision: http://reviews.llvm.org/D18564 llvm-svn: 264872
* [MemorySSA] Make the visitor more careful with calls.George Burgess IV2016-03-301-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to this patch, the MemorySSA caching visitor would cache all calls that it visited. When paired with phi optimization, this can be problematic. Consider: define void @foo() { ; 1 = MemoryDef(liveOnEntry) call void @clobberFunction() br i1 undef, label %if.end, label %if.then if.then: ; MemoryUse(??) call void @readOnlyFunction() ; 2 = MemoryDef(1) call void @clobberFunction() br label %if.end if.end: ; 3 = MemoryPhi(...) ; MemoryUse(?) call void @readOnlyFunction() ret void } When optimizing MemoryUse(?), we visit defs 1 and 2, so we note to cache them later. We ultimately end up not being able to optimize passed the Phi, so we set MemoryUse(?) to point to the Phi. We then cache the clobbering call for def 1 to be the Phi. This commit changes this behavior so that we wipe out any calls added to VisistedCalls while visiting the defs of a phi we couldn't optimize. Aside: With this patch, we now can bootstrap clang/LLVM without a single MemorySSA verifier failure. Woohoo. :) llvm-svn: 264820
* [MemorySSA] Change how the walker views/walks visited phis.George Burgess IV2016-03-301-22/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch teaches the caching MemorySSA walker a few things: 1. Not to walk Phis we've walked before. It seems that we tried to do this before, but it didn't work so well in cases like: define void @foo() { %1 = alloca i8 %2 = alloca i8 br label %begin begin: ; 3 = MemoryPhi({%0,liveOnEntry},{%end,2}) ; 1 = MemoryDef(3) store i8 0, i8* %2 br label %end end: ; MemoryUse(?) load i8, i8* %1 ; 2 = MemoryDef(1) store i8 0, i8* %2 br label %begin } Because we wouldn't put Phis in Q.Visited until we tried to visit them. So, when trying to optimize MemoryUse(?): - We would visit 3 above - ...Which would make us put {%0,liveOnEntry} in Q.Visited - ...Which would make us visit {%0,liveOnEntry} - ...Which would make us put {%end,2} in Q.Visited - ...Which would make us visit {%end,2} - ...Which would make us visit 3 - ...Which would realize we've already visited everything in 3 - ...Which would make us conservatively return 3. In the added test-case, (@looped_visitedonlyonce) this behavior would cause us to give incorrect results. Specifically, we'd visit 4 twice in the same query, but on the second visit, we'd skip while.cond because it had been visited, visit if.then/if.then2, and cache "1" as the clobbering def on the way back. 2. If we try to walk the defs of a {Phi,MemLoc} and see it has been visited before, just hand back the Phi we're trying to optimize. I promise this isn't as terrible as it seems. :) We now insert {Phi,MemLoc} pairs just before walking the Phi's upward defs. So, we check the cache for the {Phi,MemLoc} pair before checking if we've already walked the Phi. The {Phi,MemLoc} pair is (almost?) always guaranteed to have a cache entry if we've already fully walked it, because we cache as we go. So, if the {Phi,MemLoc} pair isn't in cache, either: (a) we must be in the process of visiting it (in which case, we can't give a better answer in a cache-as-we-go DFS walker) (b) we visited it, but didn't cache it on the way back (...which seems to require `ModifyingAccess` to not dominate `StartingAccess`, so I'm 99% sure that would be an error. If it's not an error, I haven't been able to get it to happen locally, so I suspect it's rare.) - - - - - As a consequence of this change, we no longer skip upward defs of phis, so we can kill the `VisitedOnlyOne` check. This gives us better accuracy than we had before, at the cost of potentially doing a bit more work when we have a loop. llvm-svn: 264814
* [ThinLTO] Remove post-pass metadata linking supportTeresa Johnson2016-03-291-64/+21
| | | | | | | | | | | Since we have moved to a model where functions are imported in bulk from each source module after making summary-based importing decisions, there is no longer a need to link metadata as a postpass, and all users have been removed. This essentially reverts r255909 and follow-on fixes. llvm-svn: 264763
* [SimlifyCFG] Prevent passes from destroying canonical loop structure, ↵Hyojin Sung2016-03-291-5/+19
| | | | | | | | | | | | | | | | | especially for nested loops When eliminating or merging almost empty basic blocks, the existence of non-trivial PHI nodes is currently used to recognize potential loops of which the block is the header and keep the block. However, the current algorithm fails if the loops' exit condition is evaluated only with volatile values hence no PHI nodes in the header. Especially when such a loop is an outer loop of a nested loop, the loop is collapsed into a single loop which prevent later optimizations from being applied (e.g., transforming nested loops into simplified forms and loop vectorization). The patch augments the existing PHI node-based check by adding a pre-test if the BB actually belongs to a set of loop headers and not eliminating it if yes. llvm-svn: 264697
* Remove personality for declarations in CloneModule.Evgeniy Stepanov2016-03-281-0/+2
| | | | | | | | | | Personality is copied as part of copyFunctionAttributes, but it is invalid on a declaration. Remove the personality attribute it the function body is not cloned. Also add a verifier run over output modules in the llvm-split tool. llvm-svn: 264667
* Revert "[SimlifyCFG] Prevent passes from destroying canonical loop ↵Reid Kleckner2016-03-281-20/+5
| | | | | | | | | | structure, especially for nested loops" This reverts commit r264596. It does not compile. llvm-svn: 264604
* [SimlifyCFG] Prevent passes from destroying canonical loop structure, ↵Hyojin Sung2016-03-281-5/+20
| | | | | | | | | | | | | | | | especially for nested loops When eliminating or merging almost empty basic blocks, the existence of non-trivial PHI nodes is currently used to recognize potential loops of which the block is the header and keep the block. However, the current algorithm fails if the loops' exit condition is evaluated only with volatile values hence no PHI nodes in the header. Especially when such a loop is an outer loop of a nested loop, the loop is collapsed into a single loop which prevent later optimizations from being applied (e.g., transforming nested loops into simplified forms and loop vectorization). The patch augments the existing PHI node-based check by adding a pre-test if the BB actually belongs to a set of loop headers and not eliminating it if yes. llvm-svn: 264596
* [SimplifyLibCalls] Transform printf("%s", "a") -> putchar('a').Davide Italiano2016-03-281-0/+18
| | | | llvm-svn: 264588
* [SimplifyCFG] propagate branch metadata when creating select (PR26636)Sanjay Patel2016-03-261-2/+2
| | | | llvm-svn: 264527
* [RS4GC] Lower calls to @llvm.experimental.deoptimizeSanjoy Das2016-03-251-9/+9
| | | | | | | | | | | | | | This changes RS4GC to lower calls to ``@llvm.experimental.deoptimize`` to gc.statepoints wrapping ``__llvm_deoptimize``, and changes ``callsGCLeafFunction`` to recognize ``@llvm.experimental.deoptimize`` as a non GC leaf function. I've had to hard code the ``"__llvm_deoptimize"`` name in RewriteStatepointsForGC; since ``TargetLibraryInfo`` is available only during codegen. This isn't without precedent in the codebase, so I'm not overtly concerned. llvm-svn: 264456
* Enable non-power-of-2 #pragma unroll counts.David L Kreitzer2016-03-251-21/+31
| | | | | | | | Patch by Evgeny Stupachenko. Differential Revision: http://reviews.llvm.org/D18202 llvm-svn: 264407
* Fix bugs in the MemorySSA walker.George Burgess IV2016-03-231-17/+35
| | | | | | | | | | | | | | | | | | There are a few bugs in the walker that this patch addresses. Primarily: - Caching can break when we have multiple BBs without phis - We weren't optimizing some phis properly - Because of how the DFS iterator works, there were times where we wouldn't cache any results of our DFS I left the test cases with FIXMEs in, because I'm not sure how much effort it will take to get those to work (read: We'll probably ultimately have to end up redoing the walker, or we'll have to come up with some creative caching tricks), and more test coverage = better. Differential Revision: http://reviews.llvm.org/D18065 llvm-svn: 264180
* [ModuleUtils] Use range-based loop. NFC.Davide Italiano2016-03-231-2/+1
| | | | llvm-svn: 264122
* [LoopVersioning] Relax an assert for LCSSA PHIsAdam Nemet2016-03-221-3/+4
| | | | | | | | | | | | | When you have multiple LCSSA (single-operand) PHIs that are converted into two-operand PHIs due to versioning, only assert that the PHI currently being converted has a single operand. I.e. we don't want to check PHIs that were converted earlier in the loop. Fixes PR27023. Thanks to Karl-Johan Karlsson for the minimized testcase! llvm-svn: 264081
* [MemorySSA] Consider def-only BBs for live-in calculations.George Burgess IV2016-03-211-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | If we have a BB with only MemoryDefs, live-in calculations will ignore it. This means we get results like this: define void @foo(i8* %p) { ; 1 = MemoryDef(liveOnEntry) store i8 0, i8* %p br i1 undef, label %if.then, label %if.end if.then: ; 2 = MemoryDef(1) store i8 1, i8* %p br label %if.end if.end: ; 3 = MemoryDef(1) store i8 2, i8* %p ret void } ...When there should be a MemoryPhi in the `if.end` BB. This patch fixes that behavior. llvm-svn: 263991
* [SimplifyLibCalls] Only consider sinpi/cospi functions within the same functionDavid Majnemer2016-03-191-7/+11
| | | | | | | | | | The sinpi/cospi can be replaced with sincospi to remove unnecessary computations. However, we need to make sure that the calls are within the same function! This fixes PR26993. llvm-svn: 263875
OpenPOWER on IntegriCloud