summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* [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
* Extended support for native Windows C++ EH outliningAndrew Kaylor2015-03-111-0/+8
| | | | | | Differential Review: http://reviews.llvm.org/D7886 llvm-svn: 231981
* InstCombine: Don't fold call bitcast into args if callee is byvalDavid Majnemer2015-03-111-1/+4
| | | | | | | This fixes a bug reported here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150309/265341.html llvm-svn: 231948
* Inliner should not add callgraph edges for intrinsic calls (PR22857)Sanjay Patel2015-03-111-1/+8
| | | | | | | | | | | | The CallGraphNode function "addCalledFunction()" asserts that edges are not to intrinsics. This patch makes sure that the Inliner does not add such an edge to the callgraph. Fix for clang crash by assertion: https://llvm.org/bugs/show_bug.cgi?id=22857 Differential Revision: http://reviews.llvm.org/D8231 llvm-svn: 231927
* If a conditional branch jumps to the same target, remove the conditionPhilip Reames2015-03-101-0/+9
| | | | | | | | | | | | Given that large parts of inst combine is restricted to instructions which have one use, getting rid of a use on the condition can help the effectiveness of the optimizer. Also, it allows the condition to potentially be deleted by instcombine rather than waiting for another pass. I noticed this completely by accident in another test case. It's not anything that actually came from a real workload. p.s. We should probably do the same thing for switch instructions. Differential Revision: http://reviews.llvm.org/D8220 llvm-svn: 231881
* remove function names from comments; NFCSanjay Patel2015-03-101-29/+26
| | | | llvm-svn: 231826
* Enable loop-rotate before loop-vectorize by defaultMichael Zolotukhin2015-03-101-2/+1
| | | | llvm-svn: 231820
* [LAA-memchecks 2/3] Move number of memcheck threshold checking to LVAdam Nemet2015-03-101-1/+13
| | | | | | | | | | | | | | | | | | | | | Now the analysis won't "fail" if the memchecks exceed the threshold. It is the transform pass' responsibility to perform the check. This allows the transform pass to further analyze/eliminate the memchecks. E.g. in Loop distribution we only need to check pointers that end up in different partitions. Note that there is a slight change of functionality here. The logic in analyzeLoop is that if dependence checking fails due to non-constant distance between the pointers, another attempt is made to prove safety of the dependences purely using run-time checks. Before this patch we could fail the loop due to exceeding the memcheck threshold after the first step, now we only check the threshold in the client after the full analysis. There is no measurable compile-time effect but I wanted to record this here. llvm-svn: 231817
* remove names from comments; NFCSanjay Patel2015-03-101-11/+9
| | | | llvm-svn: 231813
* fix typos; NFCSanjay Patel2015-03-101-2/+2
| | | | llvm-svn: 231812
* remove function names from comments; NFCSanjay Patel2015-03-101-11/+9
| | | | llvm-svn: 231801
* Fix a crash in InstCombine where we could try to truncate a switch ↵Owen Anderson2015-03-101-1/+2
| | | | | | comparison to zero width. llvm-svn: 231761
* Fix an infinite loop in InstCombine when an instruction with no users and ↵Owen Anderson2015-03-101-0/+4
| | | | | | | | | | | side effects can be constant folded. ReplaceInstUsesWith needs to return nullptr when the input has no users, because in that case it does not mutate the program. Otherwise, we can get stuck in an infinite loop of repeatedly attempting to constant fold and instruction with no users. llvm-svn: 231755
* DataLayout is mandatory, update the API to reflect it with references.Mehdi Amini2015-03-1074-1681/+1482
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Now that the DataLayout is a mandatory part of the module, let's start cleaning the codebase. This patch is a first attempt at doing that. This patch is not exactly NFC as for instance some places were passing a nullptr instead of the DataLayout, possibly just because there was a default value on the DataLayout argument to many functions in the API. Even though it is not purely NFC, there is no change in the validation. I turned as many pointer to DataLayout to references, this helped figuring out all the places where a nullptr could come up. I had initially a local version of this patch broken into over 30 independant, commits but some later commit were cleaning the API and touching part of the code modified in the previous commits, so it seemed cleaner without the intermediate state. Test Plan: Reviewers: echristo Subscribers: llvm-commits From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231740
* [sanitizer] fix instrumentation with -mllvm ↵Kostya Serebryany2015-03-101-7/+10
| | | | | | -sanitizer-coverage-block-threshold=0 to actually do something useful. llvm-svn: 231736
* [sanitizer] decrease sanitizer-coverage-block-threshold from 1000 to 500 as ↵Kostya Serebryany2015-03-101-1/+1
| | | | | | another horrible workaround for PR17409 llvm-svn: 231733
* Remove the remaining uses of abs64 and nuke it.Benjamin Kramer2015-03-093-7/+7
| | | | | | std::abs works just fine and we're already using it in many places. NFC intended. llvm-svn: 231696
OpenPOWER on IntegriCloud