summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* SampleProfile: Check for missing debug locationsDuncan P. N. Exon Smith2015-03-201-0/+3
| | | | | | | | | Don't use `DebugLoc` accessors if we're pointing at null, which will be a problem after a WIP patch to make the `DIDescriptor` accessors more strict. Caught by Frontend/profile-sample-use-loc-tracking.c (in clang). llvm-svn: 232792
* Verifier: Remove the separate -verify-di passDuncan P. N. Exon Smith2015-03-192-7/+2
| | | | | | | | | | | | | | Remove `DebugInfoVerifierLegacyPass` and the `-verify-di` pass. Instead, call into the `DebugInfoVerifier` from inside `VerifierLegacyPass::finalizeModule()`. This better matches the logic in `verifyModule()` (used by the new PassManager), avoids requiring two separate passes to verify the IR, and makes the API for "add a pass to verify the IR" simple. Note: the `-verify-debug-info` flag still works (for now, at least; eventually it might make sense to just remove it). llvm-svn: 232772
* LowerBitSets: Avoid reusing byte set addresses.Peter Collingbourne2015-03-191-1/+16
| | | | | | | | | | Each use of the byte array uses a different alias. This makes the backend less likely to reuse previously computed byte array addresses, improving the security of the CFI mechanism based on this pass. Differential Revision: http://reviews.llvm.org/D8455 llvm-svn: 232770
* libLTO, llvm-lto, gold: Introduce flag for controlling optimization level.Peter Collingbourne2015-03-191-4/+12
| | | | | | | | | | This change also introduces a link-time optimization level of 1. This optimization level runs only the globaldce pass as well as cleanup passes for passes that run at -O0, specifically simplifycfg which cleans up lowerbitsets. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150316/266951.html llvm-svn: 232769
* PassManagerBuilder: Remove effectively dead 'StripDebug' optionDuncan P. N. Exon Smith2015-03-191-7/+2
| | | | | | | | | `StripDebug` was only used by tools/opt/opt.cpp in `AddStandardLinkPasses()`, but opt.cpp adds the same pass based on its command-line flag before it calls `AddStandardLinkPasses()`. Stripping debug info twice isn't very useful. llvm-svn: 232765
* GlobalDCE: Improve performance for large modules containing comdats.Peter Collingbourne2015-03-191-10/+16
| | | | | | | | | | | | | | | | When we encounter a global with a comdat, rather than iterating over every global in the module to find globals in the same comdat, store the members in a multimap. This effectively lowers the complexity to O(N log N), improving performance significantly for large modules such as might be encountered during LTO. It looks like we used to do something like this until r219191. No functional change. Differential Revision: http://reviews.llvm.org/D8431 llvm-svn: 232743
* [InstCombine] Don't fold a GEP into itself through a PHI nodeDaniel Jasper2015-03-191-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This can only occur (I think) through the back-edge of the loop. However, folding a GEP into itself means that the value of the previous iteration needs to be stored in the meantime, thus requiring an additional register variable to be live, but not actually achieving anything (the gep still needs to be executed once per loop iteration). The attached test case is derived from: typedef unsigned uint32; typedef unsigned char uint8; inline uint8 *f(uint32 value, uint8 *target) { while (value >= 0x80) { value >>= 7; ++target; } ++target; return target; } uint8 *g(uint32 b, uint8 *target) { target = f(b, f(42, target)); return target; } What happens is that the GEP stored in incptr2 is folded into itself through the loop's back-edge and the phi-node stored in loopptr, effectively incrementing the ptr by "2" in each iteration instead of "1". In this case, it is actually increasing the number of GEPs required as the GEP before the loop can't be folded away anymore. For comparison: With this patch: define i8* @test4(i32 %value, i8* %buffer) { entry: %cmp = icmp ugt i32 %value, 127 br i1 %cmp, label %loop.header, label %exit loop.header: ; preds = %entry br label %loop.body loop.body: ; preds = %loop.body, %loop.header %buffer.pn = phi i8* [ %buffer, %loop.header ], [ %loopptr, %loop.body ] %newval = phi i32 [ %value, %loop.header ], [ %shr, %loop.body ] %loopptr = getelementptr inbounds i8, i8* %buffer.pn, i64 1 %shr = lshr i32 %newval, 7 %cmp2 = icmp ugt i32 %newval, 16383 br i1 %cmp2, label %loop.body, label %loop.exit loop.exit: ; preds = %loop.body br label %exit exit: ; preds = %loop.exit, %entry %0 = phi i8* [ %loopptr, %loop.exit ], [ %buffer, %entry ] %incptr3 = getelementptr inbounds i8, i8* %0, i64 2 ret i8* %incptr3 } Without this patch: define i8* @test4(i32 %value, i8* %buffer) { entry: %incptr = getelementptr inbounds i8, i8* %buffer, i64 1 %cmp = icmp ugt i32 %value, 127 br i1 %cmp, label %loop.header, label %exit loop.header: ; preds = %entry br label %loop.body loop.body: ; preds = %loop.body, %loop.header %0 = phi i8* [ %buffer, %loop.header ], [ %loopptr, %loop.body ] %loopptr = phi i8* [ %incptr, %loop.header ], [ %incptr2, %loop.body ] %newval = phi i32 [ %value, %loop.header ], [ %shr, %loop.body ] %shr = lshr i32 %newval, 7 %incptr2 = getelementptr inbounds i8, i8* %0, i64 2 %cmp2 = icmp ugt i32 %newval, 16383 br i1 %cmp2, label %loop.body, label %loop.exit loop.exit: ; preds = %loop.body br label %exit exit: ; preds = %loop.exit, %entry %ptr2 = phi i8* [ %incptr2, %loop.exit ], [ %incptr, %entry ] %incptr3 = getelementptr inbounds i8, i8* %ptr2, i64 1 ret i8* %incptr3 } Review: http://reviews.llvm.org/D8245 llvm-svn: 232718
* [ConstantRange] Split makeICmpRegion in two.Sanjoy Das2015-03-182-4/+4
| | | | | | | | | | | | | | | | | | | | Summary: This change splits `makeICmpRegion` into `makeAllowedICmpRegion` and `makeSatisfyingICmpRegion` with slightly different contracts. The first one is useful for determining what values some expression //may// take, given that a certain `icmp` evaluates to true. The second one is useful for determining what values are guaranteed to //satisfy// a given `icmp`. Reviewers: nlewycky Reviewed By: nlewycky Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8345 llvm-svn: 232575
* Try to fix a test broken by one of my previous commits.Michael Zolotukhin2015-03-171-0/+3
| | | | llvm-svn: 232536
* LoopVectorize: teach loop vectorizer to vectorize calls.Michael Zolotukhin2015-03-171-35/+157
| | | | | | | The tests would be committed in a commit for http://reviews.llvm.org/D8131 Review: http://reviews.llvm.org/D8095 llvm-svn: 232530
* LoopVectorizer: Add TargetTransformInfo.Michael Zolotukhin2015-03-171-9/+12
| | | | | Review: http://reviews.llvm.org/D8092 llvm-svn: 232522
* [asan] remove redundant ifndefs. NFCKostya Serebryany2015-03-171-9/+5
| | | | llvm-svn: 232521
* [SwitchLowering] Remove incoming values in the reverse orderMichael Liao2015-03-171-1/+6
| | | | | | | - To prevent invalidating *successive* indices. llvm-svn: 232510
* Fix GCC -Wparentheses warning (& reformat now that the precedence is fixed)David Blaikie2015-03-171-2/+2
| | | | | | | Benign warning (clang deliberately suppresses this case) but does regularly produce bad formatting, so it's nice to fix/reformat. llvm-svn: 232508
* asan: optimization experimentsDmitry Vyukov2015-03-171-60/+114
| | | | | | | | | | | | | | | | | | | | The experiments can be used to evaluate potential optimizations that remove instrumentation (assess false negatives). Instead of completely removing some instrumentation, you set Exp to a non-zero value (mask of optimization experiments that want to remove instrumentation of this instruction). If Exp is non-zero, this pass will emit special calls into runtime (e.g. __asan_report_exp_load1 instead of __asan_report_load1). These calls make runtime terminate the program in a special way (with a different exit status). Then you run the new compiler on a buggy corpus, collect the special terminations (ideally, you don't see them at all -- no false negatives) and make the decision on the optimization. The exact reaction to experiments in runtime is not implemented in this patch. It will be defined and implemented in a subsequent patch. http://reviews.llvm.org/D8198 llvm-svn: 232502
* Use an underlying enum type of unsigned to silence a -Wmicrosoft warning ↵Reid Kleckner2015-03-171-1/+1
| | | | | | about being unable to put (unsigned)-1 into the default underyling type of int llvm-svn: 232498
* [IRCE] Add a -irce-print-range-checks option.Sanjoy Das2015-03-171-6/+15
| | | | | | | -irce-print-range-checks prints out the set of range checks recognized by IRCE. llvm-svn: 232451
* MapMetadata: Allow unresolved metadata if it won't changeDuncan P. N. Exon Smith2015-03-171-1/+5
| | | | | | | | | Allow unresolved nodes through the `MapMetadata()` if `RF_NoModuleLevelChanges`, since there's no remapping to do anyway. This fixes PR22929. I'll add a clang test as a follow-up. llvm-svn: 232449
* [IRCE] Add comments, NFC.Sanjoy Das2015-03-171-4/+27
| | | | | | | This change adds some comments that justify why a potentially overflowing operation is safe. llvm-svn: 232445
* [IRCE] Support half-range checks.Sanjoy Das2015-03-171-128/+152
| | | | | | | | | | | | This change to IRCE gets it to recognize "half" range checks. Half range checks are range checks that only either check if the index is `slt` some positive integer ("length") or if the index is `sge` `0`. The range solver does not try to be clever / aggressive about solving half-range checks -- it transforms "I < L" to "0 <= I < L" and "0 <= I" to "0 <= I < INT_SMAX". This is safe, but not always optimal. llvm-svn: 232444
* GCOV: Make the exit block placement from r223193 optionalJustin Bogner2015-03-161-7/+13
| | | | | | | | By default we want our gcov emission to stay 4.2 compatible, which means we need to continue emit the exit block last by default. We add an option to emit it before the body for users that need it. llvm-svn: 232438
* LowerBitSets: do not use private aliases at all on Darwin.Peter Collingbourne2015-03-161-12/+17
| | | | | | | LLVM currently turns these into linker-private symbols, which can be dead stripped by the Darwin linker. llvm-svn: 232435
* [llvm] Replacing asserts with static_asserts where appropriateGabor Horvath2015-03-161-1/+5
| | | | | | | | | | | | | | | | Summary: This patch consists of the suggestions of clang-tidy/misc-static-assert check. Reviewers: alexfh Reviewed By: alexfh Subscribers: xazax.hun, llvm-commits Differential Revision: http://reviews.llvm.org/D8343 llvm-svn: 232366
* asan: fix overflows in isSafeAccessDmitry Vyukov2015-03-161-3/+3
| | | | | | | | | As pointed out in http://reviews.llvm.org/D7583 The current checks can cause overflows when object size/access offset cross Quintillion bytes. http://reviews.llvm.org/D8193 llvm-svn: 232358
* One more try with unused.Michael Gottesman2015-03-161-1/+2
| | | | llvm-svn: 232357
* Add in an unreachable after a covered switch to appease certain bots.Michael Gottesman2015-03-161-0/+1
| | | | llvm-svn: 232356
* Remove a used that snuck in that seems to be triggering the MSVC buildbots.Michael Gottesman2015-03-161-2/+1
| | | | llvm-svn: 232355
* [objc-arc] Fix indentation of debug logging so it is easy to read the output.Michael Gottesman2015-03-163-19/+101
| | | | llvm-svn: 232352
* [objc-arc] Make the ARC optimizer more conservative by forcing it to be ↵Michael Gottesman2015-03-162-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | non-safe in both direction, but mitigate the problem by noting that we just care if there was a further use. The problem here is the infamous one direction known safe. I was hesitant to turn it off before b/c of the potential for regressions without an actual bug from users hitting the problem. This is that bug ; ). The main performance impact of having known safe in both directions is that often times it is very difficult to find two releases without a use in-between them since we are so conservative with determining potential uses. The one direction known safe gets around that problem by taking advantage of many situations where we have two retains in a row, allowing us to avoid that problem. That being said, the one direction known safe is unsafe. Consider the following situation: retain(x) retain(x) call(x) call(x) release(x) Then we know the following about the reference count of x: // rc(x) == N (for some N). retain(x) // rc(x) == N+1 retain(x) // rc(x) == N+2 call A(x) call B(x) // rc(x) >= 1 (since we can not release a deallocated pointer). release(x) // rc(x) >= 0 That is all the information that we can know statically. That means that we know that A(x), B(x) together can release (x) at most N+1 times. Lets say that we remove the inner retain, release pair. // rc(x) == N (for some N). retain(x) // rc(x) == N+1 call A(x) call B(x) // rc(x) >= 1 release(x) // rc(x) >= 0 We knew before that A(x), B(x) could release x up to N+1 times meaning that rc(x) may be zero at the release(x). That is not safe. On the other hand, consider the following situation where we have a must use of release(x) that x must be kept alive for after the release(x)**. Then we know that: // rc(x) == N (for some N). retain(x) // rc(x) == N+1 retain(x) // rc(x) == N+2 call A(x) call B(x) // rc(x) >= 2 (since we know that we are going to release x and that that release can not be the last use of x). release(x) // rc(x) >= 1 (since we can not deallocate the pointer since we have a must use after x). … // rc(x) >= 1 use(x) Thus we know that statically the calls to A(x), B(x) can together only release rc(x) N times. Thus if we remove the inner retain, release pair: // rc(x) == N (for some N). retain(x) // rc(x) == N+1 call A(x) call B(x) // rc(x) >= 1 … // rc(x) >= 1 use(x) We are still safe unless in the final … there are unbalanced retains, releases which would have caused the program to blow up anyways even before optimization occurred. The simplest form of must use is an additional release that has not been paired up with any retain (if we had paired the release with a retain and removed it we would not have the additional use). This fits nicely into the ARC framework since basically what you do is say that given any nested releases regardless of what is in between, the inner release is known safe. This enables us to get back the lost performance. <rdar://problem/19023795> llvm-svn: 232351
* [objc-arc] Treat memcpy, memove, memset as just using pointers, not ↵Michael Gottesman2015-03-161-34/+62
| | | | | | | | | decrementing them. This will be tested in the next commit (which required it). The commit is going to update a bunch of tests at the same time. llvm-svn: 232350
* [objc-arc] Rename ConnectTDBUTraversals => PairUpRetainsReleases.Michael Gottesman2015-03-161-15/+15
| | | | | | This is a name that is more descriptive of what the method really does. NFC. llvm-svn: 232349
* [objc-arc] Move initialization of ARCMDKindCache into the class itself. I ↵Michael Gottesman2015-03-166-21/+54
| | | | | | also made it lazy. llvm-svn: 232348
* [objc-arc] Change EntryPointType to an enum class outside of ↵Michael Gottesman2015-03-163-34/+34
| | | | | | ARCRuntimeEntryPoints called ARCRuntimeEntryPointKind. llvm-svn: 232347
* [opaque pointer type] IRBuilder gep migration progressDavid Blaikie2015-03-151-0/+5
| | | | llvm-svn: 232294
* Update InstCombine to transform aggregate stores into scalar stores.Mehdi Amini2015-03-141-0/+28
| | | | | | | | | | | | | | | | | | | Summary: This is a first step toward getting proper support for aggregate loads and stores. Test Plan: Added unittests Reviewers: reames, chandlerc Reviewed By: chandlerc Subscribers: majnemer, joker.eph, chandlerc, llvm-commits Differential Revision: http://reviews.llvm.org/D7780 Patch by Amaury Sechet From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 232284
* Add some missed formattingDavid Blaikie2015-03-141-4/+7
| | | | llvm-svn: 232281
* [opaque pointer type] gep API migration, ArgPromoDavid Blaikie2015-03-141-16/+19
| | | | | | | | | This involved threading the type-to-gep through a data structure, since the code was relying on the pointer type to carry this information. I imagine there will be a lot of this work across the project... slow work chasing each use case, but the assertions will help keep me honest. llvm-svn: 232277
* [opaque pointer type] more gep API migrationDavid Blaikie2015-03-142-10/+12
| | | | llvm-svn: 232274
* [opaque pointer type] more gep API migrationsDavid Blaikie2015-03-142-2/+3
| | | | | | | | | | Adding nullptr to all the IRBuilder stuff because it's the first thing that fails to build when testing without the back-compat functions, so I'll keep having to re-add these locally for each chunk of migration I do. Might as well check them in to save me the churn. Eventually I'll have to migrate these too, but I'm going breadth-first. llvm-svn: 232270
* [opaque pointer type] Start migrating GEP creation to explicitly specify the ↵David Blaikie2015-03-144-26/+27
| | | | | | | | | | | | | | | pointee type I'm just going to migrate these in a pretty ad-hoc & incremental way - providing the backwards compatible API for now, then locally removing it, fixing a few callers, adding it back in and commiting those callers. Rinse, repeat. The assertions should ensure that if I get this wrong we'll find out about it and not just have one giant patch to revert, recommit, revert, recommit, etc. llvm-svn: 232240
* LowerBitSets: Do not export symbols for bit set referenced globals on Darwin.Peter Collingbourne2015-03-141-1/+9
| | | | | | | The linker on that platform may re-order symbols or strip dead symbols, which will break bit set checks. Avoid this by hiding the symbols from the linker. llvm-svn: 232235
* Reapply "[Reassociate] Add initial support for vector instructions."Robert Lougher2015-03-131-19/+15
| | | | | | | | | This reapplies the patch previously committed at revision 232190. This was reverted at revision 232196 as it caused test failures in tests that did not expect operands to be commuted. I have made the tests more resilient to reassociation in revision 232206. llvm-svn: 232209
* instcombine: alloca: Canonicalize scalar allocation array sizeDuncan P. N. Exon Smith2015-03-131-2/+10
| | | | | | | | | As a follow-up to r232200, add an `-instcombine` to canonicalize scalar allocations to `i32 1`. Since r232200, `iX 1` (for X != 32) are only created by RAUWs, so this shouldn't fire too often. Nevertheless, it's a cheap check and a nice cleanup. llvm-svn: 232202
* instcombine: alloca: Limit array size type promotionDuncan P. N. Exon Smith2015-03-131-9/+9
| | | | | | | | | | | | | | Move type promotion of the size of the array allocation to the end of `simplifyAllocaArraySize()`. This avoids promoting the type of the array size if it's a `ConstantInt`, since the next -instcombine iteration will drop it to a scalar allocation anyway. Similarly, this avoids promoting the type if it's an `UndefValue`, in which case the alloca gets RAUW'ed. This is NFC when considered over the lifetime of -instcombine, since it's just reducing the number of iterations needed to reach fixed point. llvm-svn: 232201
* AsmWriter: Write alloca array size explicitly (and -instcombine fixup)Duncan P. N. Exon Smith2015-03-131-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Write the `alloca` array size explicitly when it's non-canonical. Previously, if the array size was `iX 1` (where X is not 32), the type would mutate to `i32` when round-tripping through assembly. The testcase I added fails in `verify-uselistorder` (as well as `FileCheck`), since the use-lists for `i32 1` and `i64 1` change. (Manman Ren came across this when running `verify-uselistorder` on some non-trivial, optimized code as part of PR5680.) The type mutation started with r104911, which allowed array sizes to be something other than an `i32`. Starting with r204945, we "canonicalized" to `i64` on 64-bit platforms -- and then on every round-trip through assembly, mutated back to `i32`. I bundled a fixup for `-instcombine` to avoid r204945 on scalar allocations. (There wasn't a clean way to sequence this into two commits, since the assembly change on its own caused testcase churn, and the `-instcombine` change can't be tested without the assembly changes.) An obvious alternative fix -- change `AllocaInst::AllocaInst()`, `AsmWriter` and `LLParser` to treat `intptr_t` as the canonical type for scalar allocations -- was rejected out of hand, since this required teaching them each about the data layout. A follow-up commit will add an `-instcombine` to canonicalize the scalar allocation array size to `i32 1` rather than leaving `iX 1` alone. rdar://problem/20075773 llvm-svn: 232200
* instcombine: alloca: Remove nesting in simplifyAllocaArraySize(), NFCDuncan P. N. Exon Smith2015-03-131-27/+30
| | | | llvm-svn: 232199
* instcombine: alloca: Split out simplifyAllocaArraySize(), NFCDuncan P. N. Exon Smith2015-03-131-8/+15
| | | | | | | | Follow-up commits will change some of the logic here. Splitting into a separate function simplifies the logic by allowing early returns instead of deeper nesting. llvm-svn: 232197
* Revert: "[Reassociate] Add initial support for vector instructions."Robert Lougher2015-03-131-15/+19
| | | | | | | This reverts revision 232190 due to buildbot failure reported on clang-hexagon-elf for test arm64_vtst.c. To be investigated. llvm-svn: 232196
* [Reassociate] Add initial support for vector instructions.Robert Lougher2015-03-131-19/+15
| | | | | | | | | | | | | | This patch adds initial support for vector instructions to the reassociation pass. It enables most parts of the pass to work with vectors but to keep the size of the patch small, optimization of Xor trees, canonicalization of negative constants and converting shifts to muls, etc., have been left out. This will be handled in later patches. The patch is based on an initial patch by Chad Rosier. Differential Revision: http://reviews.llvm.org/D7566 llvm-svn: 232190
* Reapply 'Run LICM pass after loop unrolling pass.'Kevin Qin2015-03-121-1/+12
| | | | | | | | | It's firstly committed at r231630, and reverted at r231635. Function pass InstructionSimplifier is inserted as barrier to make sure loop unroll pass won't affect on LICM pass. llvm-svn: 232011
OpenPOWER on IntegriCloud