summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Utils
Commit message (Collapse)AuthorAgeFilesLines
...
* ValueMapper: Hide Mapper::VM behind an accessor, NFCDuncan P. N. Exon Smith2016-04-151-29/+32
| | | | | | | | | Change Mapper::VM to a pointer and add a `getVM()` accessor for it. While this has no functionality change, it minimizes the diff on an upcoming patch that allows switching between instances of ValueToValueMapTy on a single Mapper instance. llvm-svn: 266490
* [PR27284] Reverse the ownership between DICompileUnit and DISubprogram.Adrian Prantl2016-04-151-42/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently each Function points to a DISubprogram and DISubprogram has a scope field. For member functions the scope is a DICompositeType. DIScopes point to the DICompileUnit to facilitate type uniquing. Distinct DISubprograms (with isDefinition: true) are not part of the type hierarchy and cannot be uniqued. This change removes the subprograms list from DICompileUnit and instead adds a pointer to the owning compile unit to distinct DISubprograms. This would make it easy for ThinLTO to strip unneeded DISubprograms and their transitively referenced debug info. Motivation ---------- Materializing DISubprograms is currently the most expensive operation when doing a ThinLTO build of clang. We want the DISubprogram to be stored in a separate Bitcode block (or the same block as the function body) so we can avoid having to expensively deserialize all DISubprograms together with the global metadata. If a function has been inlined into another subprogram we need to store a reference the block containing the inlined subprogram. Attached to https://llvm.org/bugs/show_bug.cgi?id=27284 is a python script that updates LLVM IR testcases to the new format. http://reviews.llvm.org/D19034 <rdar://problem/25256815> llvm-svn: 266446
* [SimplifyCFG] propagate branch metadata when creating select (PR27344)Sanjay Patel2016-04-151-2/+2
| | | | | | | | | | This is almost identical to: http://reviews.llvm.org/rL264527 This doesn't solve PR27344; it just allows the profile weights to survive. To solve the bug, we need to use the profile weights in the backend. llvm-svn: 266442
* Fix null pointer access for discriminator assignment.Dehao Chen2016-04-141-0/+2
| | | | | | | | | | | | Summary: This fixes the buildbot failure. Reviewers: dnovillo, davidxl Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D19129 llvm-svn: 266360
* Update discriminator assignment algorithm to handle nested call correctly.Dehao Chen2016-04-141-20/+14
| | | | | | | | | | | | Summary: Add discriminator for nested call correctly. Reviewers: davidxl, dnovillo Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D19127 llvm-svn: 266354
* [ValueMapper] Range-loopify to improve readability. NFC.Davide Italiano2016-04-141-3/+3
| | | | llvm-svn: 266350
* ValueMapper: Resolve cycles on the new nodesDuncan P. N. Exon Smith2016-04-131-2/+4
| | | | | | | | | | | | | | Fix a major bug from r265456. Although it's now much rarer, ValueMapper sometimes has to duplicate cycles. The might-transitively-reference-a-temporary counts don't decrement on their own when there are cycles, and you need to call MDNode::resolveCycles to fix it. r265456 was checking the input nodes to see if they were unresolved. This is useless; they should never be unresolved. Instead we should check the output nodes and resolve cycles on them. llvm-svn: 266258
* Simplify strlen to a subtraction for certain cases.David L Kreitzer2016-04-131-0/+51
| | | | | | | | Patch by Li Huang (li1.huang@intel.com) Differential Revision: http://reviews.llvm.org/D18230 llvm-svn: 266200
* Fix mismatch on returned type between header and implementation for ↵Mehdi Amini2016-04-121-1/+1
| | | | | | | createNameAnonFunctionPass() From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266151
* Add a pass to name anonymous/nameless functionMehdi Amini2016-04-123-0/+104
| | | | | | | | | | | | | | | | Summary: For correct handling of alias to nameless function, we need to be able to refer them through a GUID in the summary. Here we name them using a hash of the non-private global names in the module. Reviewers: tejohnson Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18883 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266132
* ThinLTO renaming: use module hash instead of position in the summaryMehdi Amini2016-04-111-1/+1
| | | | | | | | | This is more robust to changes in the link ordering. Differential Revision: http://reviews.llvm.org/D18946 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266018
* Fix a couple of redundant conditional expressions (PR27283, PR28282)Hans Wennborg2016-04-111-1/+1
| | | | llvm-svn: 265987
* [LoopUtils, LV] Fix PR27246 (first-order recurrences)Matthew Simpson2016-04-111-1/+1
| | | | | | | | | | | | This patch ensures that when we detect first-order recurrences, we reject a phi node if its previous value is also a phi node. During vectorization the initial and previous values of the recurrence are shuffled together to create the value for the current iteration. However, phi nodes are not widened like other instructions. This fixes PR27246. Differential Revision: http://reviews.llvm.org/D18971 llvm-svn: 265983
* This reverts commit r265913 and r265912Sanjoy Das2016-04-111-107/+0
| | | | | | | | | See PR27315 r265913: "[IndVars] Eliminate op.with.overflow when possible" r265912: "[SCEV] See through op.with.overflow intrinsics" llvm-svn: 265950
* [IndVars] Eliminate op.with.overflow when possibleSanjoy Das2016-04-101-0/+107
| | | | | | | | | | | | | | | Summary: If we can prove that an op.with.overflow intrinsic does not overflow, we can get rid of the intrinsic, and replace it with non-wrapping arithmetic. Reviewers: atrick, regehr Subscribers: sanjoy, mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D18685 llvm-svn: 265913
* Maintain calling convention when inling calls to llvm.deoptimizeSanjoy Das2016-04-091-1/+3
| | | | | | | The behavior here was buggy -- we'd forget the calling convention after inlining a callsite calling llvm.deoptimize. llvm-svn: 265867
* test commitEvgeny Stupachenko2016-04-081-2/+2
| | | | llvm-svn: 265840
* ValueMapper: Extract llvm::RemapFunction from IRMover.cpp, NFCDuncan P. N. Exon Smith2016-04-081-0/+30
| | | | | | | | | | | | | | Strip out the remapping parts of IRLinker::linkFunctionBody and put them in ValueMapper.cpp under the name Mapper::remapFunction (with a top-level entry-point llvm::RemapFunction). This is a nice cleanup on its own since it puts the remapping code together and shares a single Mapper context for the entire IRLinker::linkFunctionBody Call. Besides that, this will make it easier to break the co-recursion between IRMover.cpp and ValueMapper.cpp in follow ups. llvm-svn: 265835
* ValueMapper: Always use Mapper::mapValue from remapInstruction, NFCIDuncan P. N. Exon Smith2016-04-081-2/+1
| | | | | | | | | | | | Use Mapper::mapValue instead of llvm::MapValue from Mapper::remapInstruction when mapping an incoming block for a PHINode (follow-up to r265832). This will implicitly pass along the Materializer argument, but when this code was added in r133513 there was no Materializer argument. I suspect this call to MapValue was just missed in r182776 since it's not observable (basic blocks can't be materialized, and they don't reference other values). llvm-svn: 265833
* ValueMapper: Roll RemapInstruction into Mapper, NFCDuncan P. N. Exon Smith2016-04-081-8/+11
| | | | | | | | | | | | Add Mapper::remapInstruction, move the guts of llvm::RemapInstruction into it, and use the same Mapper for most of the calls to MapValue and MapMetadata. There should be no functionality change here. I left off the call to MapValue that wasn't passing in a Materializer argument (for basic blocks of PHINodes). It shouldn't change functionality either, but I'm suspicious enough to commit separately. llvm-svn: 265832
* ValueMapper: Don't memoize metadata when RF_NoModuleLevelChangesDuncan P. N. Exon Smith2016-04-081-1/+1
| | | | | | | | | Prevent the Metadata side-table in ValueMap from growing unnecessarily when RF_NoModuleLevelChanges. As a drive-by, make ValueMap::hasMD, which apparently had no users until I used it here for testing, actually compile. llvm-svn: 265828
* ValueMapper: Stop memoizing MDStringsDuncan P. N. Exon Smith2016-04-081-2/+6
| | | | | | | | | | | | | | | Stop adding MDString to the Metadata section of the ValueMap in MapMetadata. It blows up the size of the map for no benefit, since we can always return quickly anyway. There is a potential follow-up that I don't think I'll push on right away, but maybe someone else is interested: stop checking for a pre-mapped MDString, and move the `isa<MDString>()` checks in Mapper::mapSimpleMetadata and MDNodeMapper::getMappedOp in front of the `VM.getMappedMD()` calls. While this would preclude explicitly remapping MDStrings it would probably be a little faster. llvm-svn: 265827
* Reapply "ValueMapper: Treat LocalAsMetadata more like function-local Values"Duncan P. N. Exon Smith2016-04-081-23/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit r265765, reapplying r265759 after changing a call from LocalAsMetadata::get to ValueAsMetadata::get (and adding a unit test). When a local value is mapped to a constant (like "i32 %a" => "i32 7"), the new debug intrinsic operand may no longer be pointing at a local. http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/19020/ The previous coommit message follows: -- 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: 265768
* 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
OpenPOWER on IntegriCloud