summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* [LAA] Merge memchecks for accesses separated by a constant offsetSilviu Baranga2015-07-081-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Often filter-like loops will do memory accesses that are separated by constant offsets. In these cases it is common that we will exceed the threshold for the allowable number of checks. However, it should be possible to merge such checks, sice a check of any interval againt two other intervals separated by a constant offset (a,b), (a+c, b+c) will be equivalent with a check againt (a, b+c), as long as (a,b) and (a+c, b+c) overlap. Assuming the loop will be executed for a sufficient number of iterations, this will be true. If not true, checking against (a, b+c) is still safe (although not equivalent). As long as there are no dependencies between two accesses, we can merge their checks into a single one. We use this technique to construct groups of accesses, and then check the intervals associated with the groups instead of checking the accesses directly. Reviewers: anemet Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10386 llvm-svn: 241673
* Allow constfolding of llvm.sin.* and llvm.cos.* intrinsicsKarthik Bhat2015-07-081-0/+22
| | | | | | | | This patch const folds llvm.sin.* and llvm.cos.* intrinsics whenever feasible. Differential Revision: http://reviews.llvm.org/D10836 llvm-svn: 241665
* Rename llvm.frameescape and llvm.framerecover to localescape and localrecoverReid Kleckner2015-07-072-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Initially, these intrinsics seemed like part of a family of "frame" related intrinsics, but now I think that's more confusing than helpful. Initially, the LangRef specified that this would create a new kind of allocation that would be allocated at a fixed offset from the frame pointer (EBP/RBP). We ended up dropping that design, and leaving the stack frame layout alone. These intrinsics are really about sharing local stack allocations, not frame pointers. I intend to go further and add an `llvm.localaddress()` intrinsic that returns whatever register (EBP, ESI, ESP, RBX) is being used to address locals, which should not be confused with the frame pointer. Naming suggestions at this point are welcome, I'm happy to re-run sed. Reviewers: majnemer, nicholas Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11011 llvm-svn: 241633
* change CHECK to CHECK-LABEL for more precisionSanjay Patel2015-07-051-1/+1
| | | | llvm-svn: 241422
* remove unnecessary test specificationsSanjay Patel2015-07-051-5/+4
| | | | llvm-svn: 241419
* minimize test case and remove unnecessary opt passesSanjay Patel2015-07-051-65/+24
| | | | llvm-svn: 241418
* Make an X86 specific directory and put the recent X86 tti specificEric Christopher2015-07-022-1/+4
| | | | | | inlining test into it. llvm-svn: 241223
* Implement TargetTransformInfo::hasCompatibleFunctionAttributes for X86.Eric Christopher2015-07-021-0/+35
| | | | | | | | | | | | | | | | | | | This checks subtarget feature compatibility for inlining by verifying that the callee is a strict subset of the caller's features. This includes the cpu as part of the subtarget we can get via the incoming functions as the backend takes CPUs as feature sets. This allows us to inline things like: int foo() { return baz(); } int __attribute__((target("sse4.2"))) bar() { return foo(); } so that generic code can be inlined into specialized functions. llvm-svn: 241221
* [TwoAddressInstructionPass] Try 3 Addr Conversion After Commuting.Quentin Colombet2015-07-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | TwoAddressInstructionPass stops after a successful commuting but 3 Addr conversion might be good for some cases. Consider: int foo(int a, int b) { return a + b; } Before this commit, we emit: addl %esi, %edi movl %edi, %eax ret After this commit, we try 3 Addr conversion: leal (%rsi,%rdi), %eax ret Patch by Volkan Keles <vkeles@apple.com>! Differential Revision: http://reviews.llvm.org/D10851 llvm-svn: 241206
* [LoopVectorize] Use ReplaceInstWithInst() helper where appropriate.Alexey Samsonov2015-07-011-15/+30
| | | | | | | | | | This is mostly an NFC, which increases code readability (instead of saving old terminator, generating new one in front of old, and deleting old, we just call a function). However, it would additionaly copy the debug location from old instruction to replacement, which would help PR23837. llvm-svn: 241197
* [LoopUnroll] Use undef for phis with no value liveDavid Majnemer2015-07-011-0/+24
| | | | | | | | We would create a phi node with a zero initialized operand instead of undef in the case where no value was originally available. This was problematic for x86_mmx which has no null value. llvm-svn: 241143
* [SCCP] Turn loads of null into undef instead of zero initialized valuesDavid Majnemer2015-07-011-0/+5
| | | | | | | | | | Surprisingly, this is a correctness issue: the mmx type exists for calling convention purposes, LLVM doesn't have a zero representation for them. This partially fixes PR23999. llvm-svn: 241142
* [NaryReassociate] enhances nsw by leveraging @llvm.assumeJingyue Wu2015-07-011-0/+36
| | | | | | | | | | | | | | | | | | | | | Summary: nsw are flaky and can often be removed by optimizations. This patch enhances nsw by leveraging @llvm.assume in the IR. Specifically, NaryReassociate now understands that assume(a + b >= 0) && assume(a >= 0) ==> a +nsw b As a result, it can split more sext(a + b) into sext(a) + sext(b) for CSE. Test Plan: nary-gep.ll Reviewers: broune, meheff Subscribers: jholewinski, llvm-commits Differential Revision: http://reviews.llvm.org/D10822 llvm-svn: 241139
* Correct a typo for a LoopVectorize testDavid Majnemer2015-06-301-1/+1
| | | | | | I forgot to specify the correct pass. llvm-svn: 241054
* [LoopSimplify] Set proper debug location in loop backedge blocks.Alexey Samsonov2015-06-291-11/+27
| | | | | | | | | | | | | Set debug location for terminator instruction in loop backedge block (which is an unconditional jump to loop header). We can't copy debug location from original backedges, as there can be several of them, with different debug info locations. So, we follow the approach of SplitBlockPredecessors, and copy the debug info from first non-PHI instruction in the header (i.e. destination block). This is yet another change for PR23837. llvm-svn: 240999
* [SLSR] S's basis must have the same type as SJingyue Wu2015-06-281-0/+20
| | | | llvm-svn: 240910
* [LoopVectorize] Pointer indicies may be wider than the pointerDavid Majnemer2015-06-271-0/+20
| | | | | | | | | | | If we are dealing with a pointer induction variable, isInductionPHI gives back a step value of Stride / size of pointer. However, we might be indexing with a legal type wider than the pointer width. Handle this by inserting casts where appropriate instead of crashing. This fixes PR23954. llvm-svn: 240877
* [PruneEH] A naked, noinline function can return via InlineAsmDavid Majnemer2015-06-271-0/+21
| | | | | | | | | | The PruneEH pass tries to annotate functions as 'noreturn' if it doesn't see a ReturnInst. However, a naked function containing inline assembly can contain control flow leaving the function. This fixes PR23971. llvm-svn: 240876
* LowerBitSets: Ignore bitset entries that do not directly refer to a global.Peter Collingbourne2015-06-271-0/+19
| | | | | | | | | | | | | | | | | It is possible for a global to be substituted with another global of a different type or a different kind (i.e. an alias) at IR link time. One example of this scenario is when a Microsoft ABI vtable is substituted with an alias referring to a larger vtable containing an RTTI reference. This will cause the global to be RAUW'd with a possibly bitcasted reference to the other global. This will of course also affect any references to the global in bitset metadata. The right way to handle such metadata is simply to ignore it. This is sound because the linked module should contain another copy of the bitset entries as applied to the new global. llvm-svn: 240866
* [RewriteStatepointsForGC] Generalized vector phi/select handling for base ↵Philip Reames2015-06-261-2/+42
| | | | | | | | | | | | | | | pointers This change extends the detection of base pointers for vector constructs to handle arbitrary phi and select nodes. The existing non-vector code already handles those, so this is basically just extending the vector special case to be less special cased. It still isn't generalized vector handling since we can't handle arbitrary vector instructions (e.g. shufflevectors), but it's a lot closer. The general structure of the change is as follows: * Extend the base defining value relation over a subset of vector instructions and vector typed phi & select instructions. * Move scalarization from before base pointer rewriting to after base pointer rewriting. The extension of the BDV relation is sufficient to find vector base phis for vector inputs. * Preserve the existing special case logic for when the base of a vector element is locally obvious. This general idea could be extended to the scalar case as well. Differential Revision: http://reviews.llvm.org/D10461#inline-84275 llvm-svn: 240850
* Teach InlineCost to account for a null check which can be folded awayPhilip Reames2015-06-261-0/+45
| | | | | | | | | | If we have a caller that knows a particular argument can never be null, we can exploit this fact while simplifying values in the inline cost analysis. This has the effect of reducing the cost for inlining when a null check is present in the callee, but the value is known non null in the caller. In particular, any dependent control flow can be discounted from the cost estimate. Note that we use the parameter attributes at the call site to memoize the analysis within the caller's code. The setting of this attribute is done in InstCombine, the inline cost analysis just consumes it. This is intentional and important because we want the inline cost analysis results to be easily cachable themselves. We're not currently doing so, but initial results on LTO indicate this will quickly become important. Differential Revision: http://reviews.llvm.org/D9129 llvm-svn: 240828
* [InstCombine] call SimplifyICmpInst with correct contextJingyue Wu2015-06-251-0/+22
| | | | | | | | | | | | | | | | | | | | | Summary: Fixes PR23809. Without passing the context to SimplifyICmpInst, we would use the assume to prove that the condition feeding the assume is trivially true (see isValidAssumeForContext in ValueTracking.cpp), causing the removal of the assume which may be useful for later optimizations. Test Plan: pr23800.ll Reviewers: hfinkel, majnemer Reviewed By: hfinkel Subscribers: henryhu, llvm-commits, wengxt, broune, meheff, eliben Differential Revision: http://reviews.llvm.org/D10695 llvm-svn: 240683
* GVN: If a branch has two identical successors, we cannot declare either dead.Peter Collingbourne2015-06-251-0/+38
| | | | | | | | | This previously caused miscompilations as a result of phi nodes receiving undef incoming values from blocks dominated by such successors. Differential Revision: http://reviews.llvm.org/D10726 llvm-svn: 240670
* Take alignment into account in isSafeToLoadUnconditionallyArtur Pilipenko2015-06-251-0/+17
| | | | | | | | Reviewed By: hfinkel Differential Revision: http://reviews.llvm.org/D10475 llvm-svn: 240636
* [GVN] Intersect the IR flags when CSE'ing two instructionsDavid Majnemer2015-06-241-0/+14
| | | | | | | | | We performed a simple, but incomplete, intersection when it came time to CSE instructions. It didn't handle, for example, the 'exact' flag. This fixes PR23922. llvm-svn: 240595
* [Reassociate] Don't propogate flags when creating negationsDavid Majnemer2015-06-242-2/+17
| | | | | | | | | Reassociate mutated existing instructions in order to form negations which would create additional reassociate opportunities. This fixes PR23926. llvm-svn: 240593
* [LSR] canonicalize Prod*(1<<C) to Prod<<CJingyue Wu2015-06-245-6/+44
| | | | | | | | | | | | | | | | | | | | | Summary: Because LSR happens at a late stage where mul of a power of 2 is typically canonicalized to shl, this canonicalization emits code that can be better CSE'ed. Test Plan: Transforms/LoopStrengthReduce/shl.ll shows how this change makes GVN more powerful. Fixes some existing tests due to this change. Reviewers: sanjoy, majnemer, atrick Reviewed By: majnemer, atrick Subscribers: majnemer, llvm-commits Differential Revision: http://reviews.llvm.org/D10448 llvm-svn: 240573
* [LoopVectorizer] Fix bailing-out condition for OptForSize case.Michael Zolotukhin2015-06-241-0/+34
| | | | | | | | | | With option OptForSize enabled, the Loop Vectorizer is not supposed to create tail loop. The condition checking that was invalid and was not matching to the comment above. Patch by Marianne Mailhot-Sarrasin. llvm-svn: 240556
* Fix PR13851: Preserve metadata for the unswitched branchWeiming Zhao2015-06-231-0/+77
| | | | | | | This patch copies the metadata of the unswitched branch to the newly crreated branch in loop unswitch pass. llvm-svn: 240378
* [InstCombine] Optimize subtract of selects into a select of a subDavid Majnemer2015-06-231-0/+22
| | | | | | | This came up when examining some code generated by clang's IRGen for certain member pointers. llvm-svn: 240369
* [LoopDist] Improve variable names and comments in LoopVersioning class, NFCAdam Nemet2015-06-222-7/+7
| | | | | | | | As with the previous patch, the goal is to turn the class into a general loop-versioning class. This patch removes any references to loop distribution. llvm-svn: 240352
* SafeStack: Create the unsafe stack pointer on demand.Peter Collingbourne2015-06-221-0/+2
| | | | | | | This avoids creating an unnecessary undefined reference on targets such as NVPTX that require such references to be declared in asm output. llvm-svn: 240321
* [SLP] Vectorize for all-constant entries.Michael Zolotukhin2015-06-191-0/+16
| | | | | | Differential Revision: http://reviews.llvm.org/D10531 llvm-svn: 240144
* AMDGPU: Fix some places missed in renameMatt Arsenault2015-06-1918-16/+16
| | | | llvm-svn: 240143
* Move the personality function from LandingPadInst to FunctionDavid Majnemer2015-06-17110-470/+470
| | | | | | | | | | | | | | | | | | | 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-1/+2
| | | | | | | The restriction on unnamed aliases was removed in r239921. Mostly reverts r239590, but we keep the test. llvm-svn: 239923
* Reapply 239795 - [InstCombine] Propagate non-null facts to call parametersPhilip Reames2015-06-162-2/+2
| | | | | | | | | | | 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
* [InstSimplify] Allow folding of fdiv X, X with just NaNs ignoredBenjamin Kramer2015-06-161-44/+24
| | | | | | | | Any combination of +-inf/+-inf is NaN so it's already ignored with nnan and we can skip checking for ninf. Also rephrase logic in comments a bit. llvm-svn: 239821
* Revert 239795Philip Reames2015-06-163-44/+2
| | | | | | I forgot to update some clang test cases. I'll fix and resubmit tomorrow. llvm-svn: 239800
* [InstCombine] Propagate non-null facts to call parametersPhilip Reames2015-06-163-2/+44
| | | | | | | | 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-1528-0/+761
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [InstSimplify] fsub nnan x, x -> 0.0 is valid without ninfBenjamin Kramer2015-06-141-3/+3
| | | | | | | Both inf - inf and (-inf) - (-inf) are NaN, so it's already covered by nnan. llvm-svn: 239702
* [InstSimplify] Add self-fdiv identities for -ffinite-math-only.Benjamin Kramer2015-06-141-0/+77
| | | | | | | | | When NaNs and Infs are ignored we can fold X / X -> 1.0 -X / X -> -1.0 X / -X -> -1.0 llvm-svn: 239701
* LowerBitSets: Give names to aliases of unnamed bitset element objects.Peter Collingbourne2015-06-121-0/+19
| | | | | | | | 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
* [GVN] Use a simpler form of IRBuilder constructor.Alexey Samsonov2015-06-121-11/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Set proper debug location for branch added in BasicBlock::splitBasicBlock().Alexey Samsonov2015-06-111-12/+33
| | | | | | | | | | | | | | | | This improves debug locations in passes that do a lot of basic block transformations. Important case is LoopUnroll pass, the test for correct debug locations accompanies this change. Test Plan: regression test suite Reviewers: dblaikie, sanjoy Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10367 llvm-svn: 239551
* SLSR: Pass address space to isLegalAddressingModeMatt Arsenault2015-06-112-0/+109
| | | | | | | | | 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
* ArgumentPromotion: Drop sret attribute on functions that are only called ↵Peter Collingbourne2015-06-101-0/+28
| | | | | | | | | | | | | | | | | | | 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
* [GVN] Set proper debug locations for some instructions created by GVN.Alexey Samsonov2015-06-101-12/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Statepoints] Add test case to check that statepoint is marked with ↵Igor Laevsky2015-06-101-0/+24
| | | | | | | | Throwable attribute. Differential Revision: http://reviews.llvm.org/D10215 llvm-svn: 239473
OpenPOWER on IntegriCloud