summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* Fix "the the" in comments.Eric Christopher2015-06-194-4/+4
| | | | llvm-svn: 240112
* [EliminateDuplicatePHINodes] Replace custom hash map with DenseSet.Benjamin Kramer2015-06-181-51/+34
| | | | | | | While there use hash_combine instead of hand-rolled hashing. No functionality change intended. llvm-svn: 240023
* [NFC] more comments in SLSRJingyue Wu2015-06-181-0/+9
| | | | llvm-svn: 239984
* Move the personality function from LandingPadInst to FunctionDavid Majnemer2015-06-175-33/+27
| | | | | | | | | | | | | | | | | | | The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
* LowerBitSets: Do not assign names to aliases of unnamed bitset element objects.Peter Collingbourne2015-06-171-3/+2
| | | | | | | The restriction on unnamed aliases was removed in r239921. Mostly reverts r239590, but we keep the test. llvm-svn: 239923
* AVX-512: cvtusi2ss/d intrinsics.Igor Breger2015-06-171-0/+2
| | | | | | | | | Change builtin function name and signature ( add third parameter - rounding mode ). Added tests for intrinsics. Differential Revision: http://reviews.llvm.org/D10473 llvm-svn: 239888
* [PM/AA] Remove the UnknownSize static member from AliasAnalysis.Chandler Carruth2015-06-173-8/+8
| | | | | | | | This is now living in MemoryLocation, which is what it pertains to. It is also an enum there rather than a static data member which is left never defined. llvm-svn: 239886
* [PM/AA] Remove the Location typedef from the AliasAnalysis class nowChandler Carruth2015-06-1711-69/+68
| | | | | | | | | | | | that it is its own entity in the form of MemoryLocation, and update all the callers. This is an entirely mechanical change. References to "Location" within AA subclases become "MemoryLocation", and elsewhere "AliasAnalysis::Location" becomes "MemoryLocation". Hope that helps out-of-tree folks update. llvm-svn: 239885
* Refactor RecurrenceInstDescTyler Nowicki2015-06-162-45/+42
| | | | | | Moved RecurrenceInstDesc into RecurrenceDescriptor to simplify the namespaces. llvm-svn: 239862
* Reapply 239795 - [InstCombine] Propagate non-null facts to call parametersPhilip Reames2015-06-161-0/+18
| | | | | | | | | | | The original change broke clang side tests. I will be submitting those momentarily. This change includes post commit feedback on the original change from from Pete Cooper. Original Submission comments: If a parameter to a function is known non-null, use the existing parameter attributes to record that fact at the call site. This has no optimization benefit by itself - that I know of - but is an enabling change for http://reviews.llvm.org/D9129. Differential Revision: http://reviews.llvm.org/D9132 llvm-svn: 239849
* Rename Reduction variables/structures to Recurrence.Tyler Nowicki2015-06-163-86/+86
| | | | | | | | A reduction is a special kind of recurrence. In the loop vectorizer we currently identify basic reductions. Future patches will extend this to identifying basic recurrences. llvm-svn: 239835
* Revert 239795Philip Reames2015-06-161-18/+0
| | | | | | I forgot to update some clang test cases. I'll fix and resubmit tomorrow. llvm-svn: 239800
* Move logic from JumpThreading into LazyValue info to simplify caller. Philip Reames2015-06-161-51/+17
| | | | | | | | This change is hopefully NFC. The only tricky part is that I changed the context instruction being used to the branch rather than the comparison. I believe both to be correct, but the branch is strictly more powerful. With the moved code, using the branch instruction is required for the basic block comparison test to return the same result. The previous code was able to directly access both the branch and the comparison where the revised code is not. Differential Revision: http://reviews.llvm.org/D9652 llvm-svn: 239797
* modules: Add explicit dependency on intrinsics_genDuncan P. N. Exon Smith2015-06-161-0/+3
| | | | | | | | | `LLVM_ENABLE_MODULES` builds sometimes fail because `Intrinsics.td` needs to regenerate `Instrinsics.h` before anyone can include anything from the LLVM_IR module. Represent the dependency explicitly to prevent that. llvm-svn: 239796
* [InstCombine] Propagate non-null facts to call parametersPhilip Reames2015-06-161-0/+18
| | | | | | | | If a parameter to a function is known non-null, use the existing parameter attributes to record that fact at the call site. This has no optimization benefit by itself - that I know of - but is an enabling change for http://reviews.llvm.org/D9129. Differential Revision: http://reviews.llvm.org/D9132 llvm-svn: 239795
* Protection against stack-based memory corruption errors using SafeStackPeter Collingbourne2015-06-154-2/+619
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the safe stack instrumentation pass to LLVM, which separates the program stack into a safe stack, which stores return addresses, register spills, and local variables that are statically verified to be accessed in a safe way, and the unsafe stack, which stores everything else. Such separation makes it much harder for an attacker to corrupt objects on the safe stack, including function pointers stored in spilled registers and return addresses. You can find more information about the safe stack, as well as other parts of or control-flow hijack protection technique in our OSDI paper on code-pointer integrity (http://dslab.epfl.ch/pubs/cpi.pdf) and our project website (http://levee.epfl.ch). The overhead of our implementation of the safe stack is very close to zero (0.01% on the Phoronix benchmarks). This is lower than the overhead of stack cookies, which are supported by LLVM and are commonly used today, yet the security guarantees of the safe stack are strictly stronger than stack cookies. In some cases, the safe stack improves performance due to better cache locality. Our current implementation of the safe stack is stable and robust, we used it to recompile multiple projects on Linux including Chromium, and we also recompiled the entire FreeBSD user-space system and more than 100 packages. We ran unit tests on the FreeBSD system and many of the packages and observed no errors caused by the safe stack. The safe stack is also fully binary compatible with non-instrumented code and can be applied to parts of a program selectively. This patch is our implementation of the safe stack on top of LLVM. The patches make the following changes: - Add the safestack function attribute, similar to the ssp, sspstrong and sspreq attributes. - Add the SafeStack instrumentation pass that applies the safe stack to all functions that have the safestack attribute. This pass moves all unsafe local variables to the unsafe stack with a separate stack pointer, whereas all safe variables remain on the regular stack that is managed by LLVM as usual. - Invoke the pass as the last stage before code generation (at the same time the existing cookie-based stack protector pass is invoked). - Add unit tests for the safe stack. Original patch by Volodymyr Kuznetsov and others at the Dependable Systems Lab at EPFL; updates and upstreaming by myself. Differential Revision: http://reviews.llvm.org/D6094 llvm-svn: 239761
* [Statepoints] Skip a vector copy when uniquing values.Benjamin Kramer2015-06-131-11/+4
| | | | | | No functionality change intended. llvm-svn: 239688
* Revert 239644.Matt Wala2015-06-131-3/+1
| | | | llvm-svn: 239650
* [Scalarizer] Fix potential for stale data in Scattered across invocationsMatt Wala2015-06-121-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Scalarizer has two data structures that hold information about changes to the function, Gathered and Scattered. These are cleared in finish() at the end of runOnFunction() if finish() detects any changes to the function. However, finish() was checking for changes by only checking if Gathered was non-empty. The function visitStore() only modifies Scattered without touching Gathered. As a result, Scattered could have ended up having stale data if Scalarizer only scalarized store instructions. Since the data in Scattered is used during the execution of the pass, this introduced dangling pointer errors. The fix is to check whether both Scattered and Gathered are empty before deciding what to do in finish(). Reviewers: srhines Reviewed By: srhines Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10422 llvm-svn: 239644
* Fix a typo in a comment in MemCpyOpt (test commit)Matt Wala2015-06-121-1/+1
| | | | llvm-svn: 239628
* [ASan] format AddressSanitizer.cpp with `clang-format -style=Google`, NFCAlexander Potapenko2015-06-121-12/+8
| | | | llvm-svn: 239601
* LowerBitSets: Give names to aliases of unnamed bitset element objects.Peter Collingbourne2015-06-121-2/+3
| | | | | | | | It is valid for globals to be unnamed, but aliases must have a name. To avoid creating invalid IR, we need to assign names to any aliases we create that point to unnamed objects that have been moved into combined globals. llvm-svn: 239590
* Revert commit r239480 as it causes ↵Teresa Johnson2015-06-123-109/+0
| | | | | | https://code.google.com/p/chromium/issues/detail?id=499508#c3. llvm-svn: 239589
* [SanitizerCoverage] Use llvm::getDISubprogram() to get location of the entry ↵Alexey Samsonov2015-06-121-3/+9
| | | | | | | | | | | basic block. DebugLoc::getFnDebugLoc() should soon be removed. Also, getDISubprogram() might become more effective soon and wouldn't need to scan debug locations at all, if function-level metadata would be emitted by Clang. llvm-svn: 239586
* [GVN] Use a simpler form of IRBuilder constructor.Alexey Samsonov2015-06-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: A side effect of this change is that it IRBuilder now automatically created debug info locations for new instructions, which is the same as debug location of insertion point. This is fine for the functions in questions (GetStoreValueForLoad and GetMemInstValueForLoad), as they are used in two situations: * GVN::processLoad, which tries to eliminate a load. In this case new instructions would have the same debug location as the load they eventually replace; * MaterializeAdjustedValue, which adds new instructions to the end of the basic blocks, which could later be used to replace the load definition. In this case we don't yet know the way the load would be eventually replaced (either by assembling the precomputed values via PHI, or by using them directly), so just using the basic block strategy seems to be reasonable. There is also a special case in the code that *would* adjust the location of the last instruction replacing the load definition to the location of the load. Test Plan: regression test suite Reviewers: echristo, dberlin, dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10405 llvm-svn: 239585
* [GVN] Use IRBuilder more actively instead of creating instructions manually.Alexey Samsonov2015-06-121-20/+21
| | | | llvm-svn: 239584
* Update stale comment before analyzeLoopUnrollCost. NFC.Michael Zolotukhin2015-06-111-7/+9
| | | | llvm-svn: 239565
* [LoopUnroll] Use IRBuilder to create branch instructions.Alexey Samsonov2015-06-111-10/+9
| | | | | | | | | | | | | | | | | | Use IRBuilder::Create(Cond)?Br instead of constructing instructions manually with BranchInst::Create(). It's consistent with other uses of IRBuilder in this pass, and has an additional important benefit: Using IRBuilder will ensure that new branch instruction will get the same debug location as original terminator instruction it will eventually replace. For now I'm not adding a testcase, as currently original terminator instruction also lack debug location due to missing debug location propagation in BasicBlock::splitBasicBlock. That is, the testcase will accompany the fix for the latter I'm going to mail soon. llvm-svn: 239550
* SLSR: Pass address space to isLegalAddressingModeMatt Arsenault2015-06-111-1/+3
| | | | | | | | | This only updates one of the uses. The other is used in cases that may never touch memory, so I'm not sure why this is even calling it. Perhaps there should be a new, similar hook for such cases or pass -1 for unknown address space. llvm-svn: 239540
* [LoopVectorize] Revert the enabling of interleaved memory access in Loop ↵Hao Liu2015-06-111-1/+1
| | | | | | Vectorizor, which was wrongly committed in r239514. llvm-svn: 239515
* [AArch64] Match interleaved memory accesses into ldN/stN instructions.Hao Liu2015-06-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Add a pass AArch64InterleavedAccess to identify and match interleaved memory accesses. This pass transforms an interleaved load/store into ldN/stN intrinsic. As Loop Vectorizor disables optimization on interleaved accesses by default, this optimization is also disabled by default. To enable it by "-aarch64-interleaved-access-opt=true" E.g. Transform an interleaved load (Factor = 2): %wide.vec = load <8 x i32>, <8 x i32>* %ptr %v0 = shuffle %wide.vec, undef, <0, 2, 4, 6> ; Extract even elements %v1 = shuffle %wide.vec, undef, <1, 3, 5, 7> ; Extract odd elements Into: %ld2 = { <4 x i32>, <4 x i32> } call aarch64.neon.ld2(%ptr) %v0 = extractelement { <4 x i32>, <4 x i32> } %ld2, i32 0 %v1 = extractelement { <4 x i32>, <4 x i32> } %ld2, i32 1 E.g. Transform an interleaved store (Factor = 2): %i.vec = shuffle %v0, %v1, <0, 4, 1, 5, 2, 6, 3, 7> ; Interleaved vec store <8 x i32> %i.vec, <8 x i32>* %ptr Into: %v0 = shuffle %i.vec, undef, <0, 1, 2, 3> %v1 = shuffle %i.vec, undef, <4, 5, 6, 7> call void aarch64.neon.st2(%v0, %v1, %ptr) llvm-svn: 239514
* ArgumentPromotion: Drop sret attribute on functions that are only called ↵Peter Collingbourne2015-06-101-0/+18
| | | | | | | | | | | | | | | | | | | directly. If the first argument to a function is a 'this' argument and the second has the sret attribute, the ArgumentPromotion pass may promote the 'this' argument to more than one argument, violating the IR constraint that 'sret' may only be applied to the first or second argument. Although this IR constraint is arguably unnecessary, it highlighted the fact that ArgPromotion does not need to preserve this attribute. Dropping the attribute reduces register pressure in the backend by avoiding the register copy required by sret. Because sret implies noalias, we also replace the former with the latter. Differential Revision: http://reviews.llvm.org/D10353 llvm-svn: 239488
* Add new EliminateAvailableExternally module pass, which is performed inTeresa Johnson2015-06-103-0/+109
| | | | | | | | | | | | | | | | O2 compiles just before GlobalDCE, unless we are preparing for LTO. This pass eliminates available externally globals (turning them into declarations), regardless of whether they are dead/unreferenced, since we are guaranteed to have a copy available elsewhere at link time. This enables additional opportunities for GlobalDCE. If we are preparing for LTO (e.g. a -flto -c compile), the pass is not included as we want to preserve available externally functions for possible link time inlining. The FE indicates whether we are doing an -flto compile via the new PrepareForLTO flag on the PassManagerBuilder. llvm-svn: 239480
* [GVN] Set proper debug locations for some instructions created by GVN.Alexey Samsonov2015-06-101-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Determining proper debug locations for instructions created in PHITransAddr is tricky. We use a simple approach here and simply copy debug locations from instructions computing load address to "corresponding" instructions re-creating the address computation in predecessor basic blocks. This may not always be correct, given all the rearrangement and simplification going on, and debug locations may jump around a lot, as the basic blocks we copy locations between may be very far from each other. Still, this would work good in most simple cases (e.g. when chain of address computing instruction is short, or our mapping turns out to be 1-to-1), and we desire to have *some* reasonable debug locations associated with newly inserted instructions. See http://reviews.llvm.org/D10351 review thread for more details. Test Plan: regression test suite Reviewers: spatel, dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10351 llvm-svn: 239479
* [BasicBlockUtils] Set debug locations for instructions created in ↵Alexey Samsonov2015-06-092-4/+5
| | | | | | | | | | | | | | SplitBlockPredecessors. Test Plan: regression test suite Reviewers: eugenis, dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10343 llvm-svn: 239438
* Remove DisableTailCalls from TargetOptions and the code in resetTargetOptionsAkira Hatanaka2015-06-092-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | that was resetting it. Remove the uses of DisableTailCalls in subclasses of TargetLowering and use the value of function attribute "disable-tail-calls" instead. Also, unconditionally add pass TailCallElim to the pipeline and check the function attribute at the start of runOnFunction to disable the pass on a per-function basis. This is part of the work to remove TargetMachine::resetTargetOptions, and since DisableTailCalls was the last non-fast-math option that was being reset in that function, we should be able to remove the function entirely after the work to propagate IR-level fast-math flags to DAG nodes is completed. Out-of-tree users should remove the uses of DisableTailCalls and make changes to attach attribute "disable-tail-calls"="true" or "false" to the functions in the IR. rdar://problem/13752163 Differential Revision: http://reviews.llvm.org/D10099 llvm-svn: 239427
* MergeFunctions: Don't replace a weak function use by another equivalent weak ↵Arnold Schwaighofer2015-06-091-15/+13
| | | | | | | | | | function We don't know whether the weak functions definition is the definitive definition. rdar://21303727 llvm-svn: 239422
* MergeFunctions: Fix gcc warning in conditionDenis Protivensky2015-06-091-2/+2
| | | | llvm-svn: 239391
* [asan] Prevent __attribute__((annotate)) triggering errors on DarwinAnna Zaks2015-06-091-14/+14
| | | | | | | | | | | | | | | | | The following code triggers a fatal error in the compiler instrumentation of ASan on Darwin because we place the attribute into llvm.metadata section, which does not have the proper MachO section name. void foo() __attribute__((annotate("custom"))); void foo() {;} This commit reorders the checks so that we skip everything in llvm.metadata first. It also removes the hard failure in case the section name does not parse. That check will be done lower in the compilation pipeline anyway. (Reviewed in http://reviews.llvm.org/D9093.) llvm-svn: 239379
* Fix unused variable warningArnold Schwaighofer2015-06-091-0/+1
| | | | llvm-svn: 239369
* MergeFunctions: Impose a total order on the replacement of functionsArnold Schwaighofer2015-06-091-1/+44
| | | | | | | | | | | | | We don't want to replace function A by Function B in one module and Function B by Function A in another module. If these functions are marked with linkonce_odr we would end up with a function stub calling B in one module and a function stub calling A in another module. If the linker decides to pick these two we will have two stubs calling each other. rdar://21265586 llvm-svn: 239367
* [ARM] Pass a callback to FunctionPass constructors to enable skipping executionAkira Hatanaka2015-06-081-3/+12
| | | | | | | | | | | | | | | | on a per-function basis. Previously some of the passes were conditionally added to ARM's pass pipeline based on the target machine's subtarget. This patch makes changes to add those passes unconditionally and execute them conditonally based on the predicate functor passed to the pass constructors. This enables running different sets of passes for different functions in the module. rdar://problem/20542263 Differential Revision: http://reviews.llvm.org/D8717 llvm-svn: 239325
* [LoopVectorize] Teach Loop Vectorizor about interleaved memory accesses.Hao Liu2015-06-081-2/+699
| | | | | | | | | | | | | | | | | | | | | | | | Interleaved memory accesses are grouped and vectorized into vector load/store and shufflevector. E.g. for (i = 0; i < N; i+=2) { a = A[i]; // load of even element b = A[i+1]; // load of odd element ... // operations on a, b, c, d A[i] = c; // store of even element A[i+1] = d; // store of odd element } The loads of even and odd elements are identified as an interleave load group, which will be transfered into vectorized IRs like: %wide.vec = load <8 x i32>, <8 x i32>* %ptr %vec.even = shufflevector <8 x i32> %wide.vec, <8 x i32> undef, <4 x i32> <i32 0, i32 2, i32 4, i32 6> %vec.odd = shufflevector <8 x i32> %wide.vec, <8 x i32> undef, <4 x i32> <i32 1, i32 3, i32 5, i32 7> The stores of even and odd elements are identified as an interleave store group, which will be transfered into vectorized IRs like: %interleaved.vec = shufflevector <4 x i32> %vec.even, %vec.odd, <8 x i32> <i32 0, i32 4, i32 1, i32 5, i32 2, i32 6, i32 3, i32 7> store <8 x i32> %interleaved.vec, <8 x i32>* %ptr This optimization is currently disabled by defaut. To try it by adding '-enable-interleaved-mem-accesses=true'. llvm-svn: 239291
* Remove SCEVCache and FindConstantPointers from complete loop unrolling ↵Michael Zolotukhin2015-06-081-212/+89
| | | | | | | | | | | | | | | | | | | | heuristic. Summary: Using some SCEV functionality helped to entirely remove SCEVCache class and FindConstantPointers SCEV visitor. Also, this makes the code more universal - I'll take advandate of it in next patches where I start handling additional types of instructions. Test Plan: Tests would be submitted in subsequent patches. Reviewers: atrick, chandlerc Reviewed By: atrick, chandlerc Subscribers: atrick, llvm-commits Differential Revision: http://reviews.llvm.org/D10205 llvm-svn: 239282
* SeparateConstOffsetFromGEP: Pass address space to isLegalAddressingModeMatt Arsenault2015-06-071-1/+3
| | | | llvm-svn: 239262
* Make NaryReassociate pass the address space to isLegalAddressingModeMatt Arsenault2015-06-071-1/+3
| | | | | | | No test since the kinds of transforms this prevents seem to not really be relevant for SI's different addressing modes. llvm-svn: 239261
* Remove global std::string. NFC.Benjamin Kramer2015-06-071-1/+1
| | | | llvm-svn: 239254
* [InstCombine, InstSimplify] Move xforms from Combine to SimplifyDavid Majnemer2015-06-061-115/+2
| | | | | | | | There were several SelectInst combines that always returned an existing instruction instead of modifying an old one or creating a new one. These are prime candidates for moving to InstSimplify. llvm-svn: 239229
* [LoopUnroll] Fix truncation bug in canUnrollCompletely.Sanjoy Das2015-06-061-3/+3
| | | | | | | | | | | | | | | | | Summary: canUnrollCompletely takes `unsigned` values for `UnrolledCost` and `RolledDynamicCost` but is passed in `uint64_t`s that are silently truncated. Because of this, when `UnrolledSize` is a large integer that has a small remainder with UINT32_MAX, LLVM tries to completely unroll loops with high trip counts. Reviewers: mzolotukhin, chandlerc Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10293 llvm-svn: 239218
* [CVP] Don't assume Constants of type i1 can be known to be true or falseDavid Majnemer2015-06-061-3/+4
| | | | | | | | | | | | | CVP wants to analyze the condition operand of a select along an edge. It succeeds in getting back a Constant but not a ConstantInt. Instead, it gets a ConstantExpr. It then assumes that the Constant must be equal to false because it isn't equal to true. Instead, perform an additional comparison. This fixes PR23752. llvm-svn: 239217
OpenPOWER on IntegriCloud