summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* Revert r233062 ""float2int": Add a new pass to demote from float to int ↵Hans Wennborg2015-03-244-545/+0
| | | | | | | | | | | where possible." This caused PR23008, compiles failing with: "Use still stuck around after Def is destroyed: %.sroa.speculated" Also reverting follow-up r233064. llvm-svn: 233105
* [IRCE] Fix how IRCE checks for no-sign-overflow.Sanjoy Das2015-03-241-14/+24
| | | | | | | | | IRCE requires the induction variables it handles to not sign-overflow. The current scheme of checking if sext({X,+,S}) == {sext(X),+,sext(S)} fails when SCEV simplifies sext(X) too. After this change we //also// check no-signed-wrap by looking at the flags set on the SCEVAddRecExpr. llvm-svn: 233102
* [IRCE] Fix a regression introduced in r232444.Sanjoy Das2015-03-241-9/+20
| | | | | | | IRCE should not try to eliminate range checks that check an induction variable against a loop-varying length. llvm-svn: 233101
* [float2int] Sort includes and add missing raw_ostream include.Benjamin Kramer2015-03-241-6/+7
| | | | llvm-svn: 233064
* "float2int": Add a new pass to demote from float to int where possible.James Molloy2015-03-244-0/+544
| | | | | | | | | | | | It is possible to have code that converts from integer to float, performs operations then converts back, and the result is provably the same as if integers were used. This can come from different sources, but the most obvious is a helper function that uses floats but the arguments given at an inlined callsites are integers. This pass considers all integers requiring a bitwidth less than or equal to the bitwidth of the mantissa of a floating point type (23 for floats, 52 for doubles) as exactly representable in floating point. To reduce the risk of harming efficient code, the pass only attempts to perform complete removal of inttofp/fptoint operations, not just move them around. llvm-svn: 233062
* Re-sort includes with sort-includes.py and insert raw_ostream.h where it's used.Benjamin Kramer2015-03-2333-45/+51
| | | | llvm-svn: 232998
* [ctorutils] Update and sort includes. NFC.Benjamin Kramer2015-03-231-1/+2
| | | | llvm-svn: 232995
* Another set of missing raw_ostream.h. Still no functional change.Benjamin Kramer2015-03-231-1/+2
| | | | llvm-svn: 232993
* Purge unused includes throughout libSupport.Benjamin Kramer2015-03-231-0/+1
| | | | | | NFC. llvm-svn: 232976
* Move private classes into anonymous namespacesBenjamin Kramer2015-03-231-0/+2
| | | | | | NFC. llvm-svn: 232944
* [SimplifyLibCalls] Fix negative shifts being produced by the memchr -> ↵Benjamin Kramer2015-03-211-1/+3
| | | | | | bitfield transform. llvm-svn: 232903
* [SimplifyLibCalls] Turn memchr(const, C, const) into a bitfield check.Benjamin Kramer2015-03-211-4/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | strchr("123!", C) != nullptr is a common pattern to check if C is one of 1, 2, 3 or !. If the largest element of the string is smaller than the target's register size we can easily create a bitfield and just do a simple test for set membership. int foo(char C) { return strchr("123!", C) != nullptr; } now becomes cmpl $64, %edi ## range check sbbb %al, %al movabsq $0xE000200000001, %rcx btq %rdi, %rcx ## bit test sbbb %cl, %cl andb %al, %cl ## and the two conditions andb $1, %cl movzbl %cl, %eax ## returning an int ret (imho the backend should expand this into a series of branches, but that's a different story) The code is currently limited to bit fields that fit in a register, so usually 64 or 32 bits. Sadly, this misses anything using alpha chars or {}. This could be fixed by just emitting a i128 bit field, but that can generate really ugly code so we have to find a better way. To some degree this is also recreating switch lowering logic, but we can't simply emit a switch instruction and thus change the CFG within instcombine. llvm-svn: 232902
* SimplifyLibCalls: Add basic optimization of memchr calls.Benjamin Kramer2015-03-211-0/+40
| | | | | | This is just memchr(x, y, 0) -> nullptr and constant folding. llvm-svn: 232896
* [sanitizer] experimental tracing for cmp instructionsKostya Serebryany2015-03-211-13/+50
| | | | llvm-svn: 232873
* [X86, AVX] instcombine common cases of vperm2* intrinsics into shufflesSanjay Patel2015-03-201-0/+59
| | | | | | | | | | | | | | | | | | | | vperm2* intrinsics are just shuffles. In a few special cases, they're not even shuffles. Optimizing intrinsics in InstCombine is better than handling this in the front-end for at least two reasons: 1. Optimizing custom-written SSE intrinsic code at -O0 makes vector coders really angry (and so I have regrets about some patches from last week). 2. Doing mask conversion logic in header files is hard to write and subsequently read. There are a couple of TODOs in this patch to complete this optimization. Differential Revision: http://reviews.llvm.org/D8486 llvm-svn: 232852
* Fixing a bug with WinEH PHI handlingAndrew Kaylor2015-03-201-4/+11
| | | | llvm-svn: 232851
* SanitizerCoverage: Check for null DebugLocsDuncan P. N. Exon Smith2015-03-201-2/+3
| | | | | | | After a WIP patch to make `DIDescriptor` accessors more strict, this started asserting. llvm-svn: 232832
* 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
OpenPOWER on IntegriCloud