summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix layering between SCCP and IPO SCCPDavid Blaikie2018-03-223-57/+62
| | | | | | | | | | Transforms/Scalar/SCCP.cpp implemented both the Scalar and IPO SCCP, but this meant Transforms/Scalar including Transfroms/IPO headers, creating a circular dependency. (IPO depends on Scalar already) - so move the IPO SCCP shims out into IPO and the basic library implementation accessible from Scalar/SCCP.h to be used from the IPO/SCCP.cpp implementation. llvm-svn: 328250
* Move the initialization of the Meta Renamer pass over to IPO along with the ↵David Blaikie2018-03-222-1/+1
| | | | | | rest of it that was moved in r328209 llvm-svn: 328234
* [InstCombineCalls] Update deprecated API usage (NFC)Daniel Neilson2018-03-221-1/+1
| | | | | | | | Summary: Just updating a call to MemSetInst::getAlignment() to MemSetInst::getDestAlignment(). The former has been deprecated. llvm-svn: 328227
* [SimplifyCFG] Create attribute for fuzzing-specific optimizations.Matt Morehouse2018-03-223-0/+9
| | | | | | | | | | | | | | | | | | | | | | Summary: When building with libFuzzer, converting control flow to selects or obscuring the original operands of CMPs reduces the effectiveness of libFuzzer's heuristics. This patch provides an attribute to disable or modify certain optimizations for optimal fuzzing signal. Provides a less aggressive alternative to https://reviews.llvm.org/D44057. Reviewers: vitalybuka, davide, arsenm, hfinkel Reviewed By: vitalybuka Subscribers: junbuml, mehdi_amini, wdng, javed.absar, hiraditya, llvm-commits, kcc Differential Revision: https://reviews.llvm.org/D44232 llvm-svn: 328214
* [LoopPredication] Add profitability check based on BPIAnna Thomas2018-03-221-3/+92
| | | | | | | | | | | | | | | | | | | | | | | | Summary: LoopPredication is not profitable when the loop is known to always exit through some block other than the latch block. A coarse grained latch check can cause loop predication to predicate the loop, and unconditionally deoptimize. However, without predicating the loop, the guard may never fail within the loop during the dynamic execution because the non-latch loop termination condition exits the loop before the latch condition causes the loop to exit. We teach LP about this using BranchProfileInfo pass. Reviewers: apilipenko, skatkov, mkazantsev, reames Reviewed by: skatkov Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44667 llvm-svn: 328210
* Move MetaRenamer from Transforms/UTils to Transforms/IPO since it implements ↵David Blaikie2018-03-223-1/+1
| | | | | | part of IPO.h llvm-svn: 328209
* [CallSiteSplitting] Preserve DominatorTreeAnalysis.Florian Hahn2018-03-221-13/+21
| | | | | | | | | | | | | | The dominator tree analysis can be preserved easily. Some other kinds of analysis can probably be preserved too. Reviewers: junbuml, dberlin Reviewed By: dberlin Differential Revision: https://reviews.llvm.org/D43173 llvm-svn: 328206
* [InstCombine] add folds for xor-of-icmp signbit tests (PR36682)Sanjay Patel2018-03-221-0/+28
| | | | | | | | | | | | | | | | | | This is a retry of r328119 which was reverted at r328145 because it could crash by trying to combine icmps with different operand types. This version has a check for that and additional tests. Original commit message: This is part of solving: https://bugs.llvm.org/show_bug.cgi?id=36682 There's also a leftover improvement from the long-ago-closed: https://bugs.llvm.org/show_bug.cgi?id=5438 https://rise4fun.com/Alive/dC1 llvm-svn: 328197
* [CloneFunction] Preserve DT in DuplicateInstructionsInSplitBetween.Florian Hahn2018-03-221-2/+3
| | | | | | | | | | | | | DuplicateInstructionsInSplitBetween can preserve the DT by passing through DT to SplitEdge. Reviewers: sanjoy, junbuml, anna, kuhar Reviewed By: kuhar Differential Revision: https://reviews.llvm.org/D44629 llvm-svn: 328189
* Fix a couple of layering violations in TransformsDavid Blaikie2018-03-2171-79/+75
| | | | | | | | | | | | | Remove #include of Transforms/Scalar.h from Transform/Utils to fix layering. Transforms depends on Transforms/Utils, not the other way around. So remove the header and the "createStripGCRelocatesPass" function declaration (& definition) that is unused and motivated this dependency. Move Transforms/Utils/Local.h into Analysis because it's used by Analysis/MemoryBuiltins.cpp. llvm-svn: 328165
* Revert r328119 "[InstCombine] add folds for xor-of-icmp signbit tests (PR36682)"Reid Kleckner2018-03-211-30/+0
| | | | | | | This asserts when compiling safe_numerics_unittest.cpp in Chromium with MSan. llvm-svn: 328145
* [InstCombine] add folds for xor-of-icmp signbit tests (PR36682)Sanjay Patel2018-03-211-0/+30
| | | | | | | | | | | | This is part of solving: https://bugs.llvm.org/show_bug.cgi?id=36682 There's also a leftover improvement from the long-ago-closed: https://bugs.llvm.org/show_bug.cgi?id=5438 https://rise4fun.com/Alive/dC1 llvm-svn: 328119
* [MemCpyOpt] Update to new API for memory intrinsic alignmentDaniel Neilson2018-03-211-25/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change is part of step five in the series of changes to remove alignment argument from memcpy/memmove/memset in favour of alignment attributes. In particular, this changes the MemCpyOpt pass to cease using: 1) The old getAlignment() API of MemoryIntrinsic in favour of getting source & dest specific alignments through the new API. 2) The old IRBuilder CreateMemCpy/CreateMemMove single-alignment APIs in favour of the new API that allows setting source and destination alignments independently. We also add a few tests to fill gaps in the testing of this pass. Steps: Step 1) Remove alignment parameter and create alignment parameter attributes for memcpy/memmove/memset. ( rL322965, rC322964, rL322963 ) Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing source and dest alignments. ( rL323597 ) Step 3) Update Clang to use the new IRBuilder API. ( rC323617 ) Step 4) Update Polly to use the new IRBuilder API. ( rL323618 ) Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API, and those that use use MemIntrinsicInst::[get|set]Alignment() to use [get|set]DestAlignment() and [get|set]SourceAlignment() instead. ( rL323886, rL323891, rL324148, rL324273, rL324278, rL324384, rL324395, rL324402, rL324626, rL324642, rL324653, rL324654, rL324773, rL324774, rL324781, rL324784, rL324955, rL324960, rL325816, rL327398, rL327421 ) Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the MemIntrinsicInst::[get|set]Alignment() methods. Reference http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html llvm-svn: 328097
* Re-re-land: Teach CorrelatedValuePropagation to reduce the width of ↵Justin Lebar2018-03-211-0/+54
| | | | | | | | | | | | | | | udiv/urem instructions. Summary: If the operands of a udiv/urem can be proved to fit within a smaller power-of-two-sized type, reduce the width of the udiv/urem. Backed out for causing performance regressions. Re-landing because we've determined that these regressions were noise. Original Differential Revision: https://reviews.llvm.org/D44102 llvm-svn: 328096
* [MustExecute] Move isGuaranteedToExecute and related rourtines to AnalysisPhilip Reames2018-03-201-133/+1
| | | | | | Next step is to actually merge the implementations and get both implementations tested through the new printer. llvm-svn: 328055
* [ObjCARC] Add funclet token to ARC markerShoaib Meenai2018-03-201-8/+27
| | | | | | | | | | | | | | | The inline assembly generated for the ARC autorelease elision marker must have a funclet token if it's emitted inside a funclet, otherwise the inline assembly (and all subsequent code in the funclet) will be marked unreachable by WinEHPrepare. Note that this only applies for the non-O0 case, since at O0, clang emits the autorelease elision marker itself rather than deferring to the backend. The fix for clang is handled in a separate change. Differential Revision: https://reviews.llvm.org/D44641 llvm-svn: 328042
* [MergeICmps] Break eargerly out of loopXin Tong2018-03-201-0/+1
| | | | llvm-svn: 327972
* [MergeICmp] Fix a bug in entry block shuffled to middle of the chainXin Tong2018-03-201-0/+11
| | | | | | | | | | | | Summary: Fix a bug in entry block shuffled to middle of the chain. Reviewers: davide, courbet Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44642 llvm-svn: 327971
* [LV] Let recordVectorLoopValueForInductionCast to check if IV was created ↵Andrei Elovikov2018-03-201-15/+37
| | | | | | | | | | | | | | | | | | | | | | from the cast. Summary: It turned out to be error-prone to expect the callers to handle that - better to leave the decision to this routine and make the required data to be explicitly passed to the function. This handles the case that was missed in the r322473 and fixes the assert mentioned in PR36524. Reviewers: dorit, mssimpso, Ayal, dcaballe Reviewed By: dcaballe Subscribers: Ka-Ka, hiraditya, dneilson, hsaito, llvm-commits Differential Revision: https://reviews.llvm.org/D43812 llvm-svn: 327960
* [InstCombine] canonicalize fcmp+select to fabsSanjay Patel2018-03-191-1/+31
| | | | | | | | | | | | | | This is complicated by -0.0 and nan. This is based on the DAG patterns as shown in D44091. I'm hoping that we can just remove those DAG folds and always rely on IR canonicalization to handle the matching to fabs. We would still need to delete the broken code from DAGCombiner to fix PR36600: https://bugs.llvm.org/show_bug.cgi?id=36600 Differential Revision: https://reviews.llvm.org/D44550 llvm-svn: 327858
* [MSan] fix the types of RegSaveAreaPtrPtr and OverflowArgAreaPtrPtrAlexander Potapenko2018-03-191-6/+6
| | | | | | | | | | | | | | Despite their names, RegSaveAreaPtrPtr and OverflowArgAreaPtrPtr used to be i8* instead of i8**. This is important, because these pointers are dereferenced twice (first in CreateLoad(), then in getShadowOriginPtr()), but for some reason MSan allowed this - most certainly because it was possible to optimize getShadowOriginPtr() away at compile time. Differential revision: https://reviews.llvm.org/D44520 llvm-svn: 327830
* [MSan] Don't create zero offsets in getShadowPtrForArgument(). NFCAlexander Potapenko2018-03-191-2/+4
| | | | | | | | | | | | | | For MSan instrumentation with MS.ParamTLS and MS.ParamOriginTLS being TLS variables, the CreateAdd() with ArgOffset==0 is a no-op, because the compiler is able to fold the addition of 0. But for KMSAN, which receives ParamTLS and ParamOriginTLS from a call to the runtime library, this introduces a stray instruction which complicates reading/testing the IR. Differential revision: https://reviews.llvm.org/D44514 llvm-svn: 327829
* [MSan] Introduce insertWarningFn(). NFCAlexander Potapenko2018-03-191-15/+16
| | | | | | | | | | | This is a step towards the upcoming KMSAN implementation patch. KMSAN is going to use a different warning function, __msan_warning_32(uptr origin), so we'd better create the warning calls in one place. Differential Revision: https://reviews.llvm.org/D44513 llvm-svn: 327828
* [LICM] Salvage DI from dying InstructionsAnastasis Grammenos2018-03-181-0/+1
| | | | | | | LICM deletes trivially dead instructions which it won't attempt to sink. Attempt to salvage debug values which reference these instructions. llvm-svn: 327800
* [InstCombine] peek through unsigned FP casts for zero-equality compares ↵Roman Lebedev2018-03-181-0/+9
| | | | | | | | | | | | | | | | | | | | | | (PR36682) Summary: This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H See also D44416 Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44424 llvm-svn: 327799
* [InstCombine] add nnan requirement for sqrt(x) * sqrt(y) -> sqrt(x*y)Sanjay Patel2018-03-181-1/+3
| | | | | | This is similar to D43765. llvm-svn: 327797
* [X86] Added support for nocf_check attribute for indirect Branch TrackingOren Ben Simhon2018-03-172-0/+2
| | | | | | | | | | | | | | | X86 Supports Indirect Branch Tracking (IBT) as part of Control-Flow Enforcement Technology (CET). IBT instruments ENDBR instructions used to specify valid targets of indirect call / jmp. The `nocf_check` attribute has two roles in the context of X86 IBT technology: 1. Appertains to a function - do not add ENDBR instruction at the beginning of the function. 2. Appertains to a function pointer - do not track the target function of this pointer by adding nocf_check prefix to the indirect-call instruction. This patch implements `nocf_check` context for Indirect Branch Tracking. It also auto generates `nocf_check` prefixes before indirect branchs to jump tables that are guarded by range checks. Differential Revision: https://reviews.llvm.org/D41879 llvm-svn: 327767
* [CorrelatedValuePropagation] Use ↵Craig Topper2018-03-161-3/+3
| | | | | | SelectInst::getCondition/getTrueValue/getFalseValue instead of getOperand for readability. NFC llvm-svn: 327728
* [LICM/mustexec] Extend first iteration must execute logic to fcmpsPhilip Reames2018-03-161-10/+9
| | | | | | | | | | This builds on the work from https://reviews.llvm.org/D44287. It turned out supporting fcmp was much easier than I realized, so let's do that now. As an aside, our -O3 handling of a floating point IVs leaves a lot to be desired. We do convert the float IV to an integer IV, but do so late enough that many other optimizations are missed (e.g. we don't vectorize). Differential Revision: https://reviews.llvm.org/D44542 llvm-svn: 327722
* [JumpThreading] Track unreachable BBs to avoid processingBrian M. Rzycki2018-03-161-47/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | JumpThreading iterates over F until the IR quiesces. Transforming unreachable BBs increases compile time and it is also possible to never stabilize causing JumpThreading to hang. An older attempt at fixing this problem was D3991 where removeUnreachableBlocks(F) was called before JumpThreading began. This has a few drawbacks: * expensive - the routine attempts to fix up the IR to identify additional BBs that can be removed along with unreachable BBs. * aggressive - does not identify and preserve the shape of the IR. At a minimum it does not preserve loop hierarchies. * invasive - altering reachable blocks it may disrupt IR shapes that could have otherwise been JumpThreaded. This patch avoids removeUnreachableBlocks(F) and instead tracks unreachable BBs in a SmallPtrSet using DominatorTree to validate the initial state of all BBs. We then rely on subsequent passes to identify and remove these unreachable blocks from F. Reviewers: dberlin, sebpop, kuhar, dinesh.d Reviewed by: sebpop, kuhar Subscribers: hiraditya, uabelho, llvm-commits Differential Revision: https://reviews.llvm.org/D44177 llvm-svn: 327713
* [LoopUnroll] Peel off iterations if it makes conditions true/false.Florian Hahn2018-03-152-5/+90
| | | | | | | | | | | | | | | If the loop body contains conditions of the form IndVar < #constant, we can remove the checks by peeling off #constant iterations. This improves codegen for PR34364. Reviewers: mkuper, mkazantsev, efriedma Reviewed By: mkazantsev Differential Revision: https://reviews.llvm.org/D43876 llvm-svn: 327671
* [LICM] Ignore exits provably not taken on first iteration when computing ↵Philip Reames2018-03-151-1/+60
| | | | | | | | | | | | | | | | must execute It is common to have conditional exits within a loop which are known not to be taken on some iterations, but not necessarily all. This patches extends our reasoning around guaranteed to execute (used when establishing whether it's safe to dereference a location from the preheader) to handle the case where an exit is known not to be taken on the first iteration and the instruction of interest *is* known to be taken on the first iteration. This case comes up in two major ways: * If we have a range check which we've been unable to eliminate, we frequently know that it doesn't fail on the first iteration. * Pass ordering. We may have a check which will be eliminated through some sequence of other passes, but depending on the exact pass sequence we might never actually do so or we might miss other optimizations from passes run before the check is finally eliminated. The initial version (here) is implemented via InstSimplify. At the moment, it catches a few cases, but misses a lot too. I added test cases for missing cases in InstSimplify which I'll follow up on separately. Longer term, we should probably wire SCEV through to here to get much smarter loop aware simplification of the first iteration predicate. Differential Revision: https://reviews.llvm.org/D44287 llvm-svn: 327664
* [LV] Test commit. Removing white space.Diego Caballero2018-03-151-1/+1
| | | | | | This is just to check that I have commit access privilege. llvm-svn: 327656
* [EarlyCSE] Don't hide earler invariant.scopesPhilip Reames2018-03-151-3/+8
| | | | | | | | If we've already established an invariant scope with an earlier generation, we don't want to hide it in the scoped hash table with one with a later generation. I noticed this when working on the invariant-load handling, but it also applies to the invariant.start case as well. Without this change, my previous patch for invariant-load regresses some cases, so I'm pushing this without waiting for review. This is why you don't make last minute tweaks to patches to catch "obvious cases" after it's already been reviewed. Bad Philip! llvm-svn: 327655
* [EarlyCSE] Reuse invariant scopes for invariant loadPhilip Reames2018-03-151-10/+13
| | | | | | | | | | This is a follow up to https://reviews.llvm.org/D43716 which rewrites the invariant load handling using the new infrastructure. It's slightly more powerful, but only in somewhat minor ways for the moment. It's not clear that DSE of stores to invariant locations is actually interesting since why would your IR have such a construct to start with? Note: The submitted version is slightly different than the reviewed one. I realized the scope could start for an invariant load which was proven redundant and removed. Added a test case to illustrate that as well. Differential Revision: https://reviews.llvm.org/D44497 llvm-svn: 327646
* [Debug] Retain both copies of debug intrinsics in HoistThenElseCodeToIfUlrich Weigand2018-03-151-25/+38
| | | | | | | | | | | | | | | | | | | | | | | | When hoisting common code from the "then" and "else" branches of a condition to before the "if", the HoistThenElseCodeToIf routine will attempt to merge the debug location associated with the two original copies of the hoisted instruction. This is a problem in the special case where the hoisted instruction is a debug info intrinsic, since for those the debug location is considered part of the intrinsic and attempting to modify it may resut in invalid IR. This is the underlying cause of PR36410. This patch fixes the problem by handling debug info intrinsics specially: instead of hoisting one copy and merging the two locations, the code now simply hoists both copies, each with its original location intact. Note that this is still only done in the case where both original copies are otherwise (i.e. apart from location metadata) identical. Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D44312 llvm-svn: 327622
* [New PM][IRCE] port of Inductive Range Check Elimination pass to the new ↵Fedor Sergeev2018-03-152-40/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | pass manager There are two nontrivial details here: * Loop structure update interface is quite different with new pass manager, so the code to add new loops was factored out * BranchProbabilityInfo is not a loop analysis, so it can not be just getResult'ed from within the loop pass. It cant even be queried through getCachedResult as LoopCanonicalization sequence (e.g. LoopSimplify) might invalidate BPI results. Complete solution for BPI will likely take some time to discuss and figure out, so for now this was partially solved by making BPI optional in IRCE (skipping a couple of profitability checks if it is absent). Most of the IRCE tests got their corresponding new-pass-manager variant enabled. Only two of them depend on BPI, both marked with TODO, to be turned on when BPI starts being available for loop passes. Reviewers: chandlerc, mkazantsev, sanjoy, asbirlea Reviewed By: mkazantsev Differential Revision: https://reviews.llvm.org/D43795 llvm-svn: 327619
* [LoopUnroll] Ignore ephemeral values when checking full unroll profitability.Andrei Elovikov2018-03-151-20/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this patch call graph is like this in the LoopUnrollPass: tryToUnrollLoop ApproximateLoopSize collectEphemeralValues /* Use collected ephemeral values */ computeUnrollCount analyzeLoopUnrollCost /* Bail out from the analysis if loop contains CallInst */ This patch moves collection of the ephemeral values to the tryToUnrollLoop function and passes the collected values into both ApproximateLoopsize (as before) and additionally starts using them in analyzeLoopUnrollCost: tryToUnrollLoop collectEphemeralValues ApproximateLoopSize(EphValues) /* Use EphValues */ computeUnrollCount(EphValues) analyzeLoopUnrollCost(EphValues) /* Ignore ephemeral values - they don't contribute to the final cost */ /* Bail out from the analysis if loop contains CallInst */ Reviewers: mzolotukhin, evstupac, sanjoy Reviewed By: evstupac Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43931 llvm-svn: 327617
* Remove unused variable; NFCGeorge Burgess IV2018-03-151-1/+0
| | | | llvm-svn: 327597
* [CleanUp] Remove NumInstructions field from LoopVectorizer's RegisterUsage ↵Matt Davis2018-03-141-7/+0
| | | | | | | | | | | | | | | | | | | | | struct. Summary: This variable is largely going unused; aside from reporting number of instructions for in DEBUG builds. The only use of NumInstructions is in debug output to represent the LoopSize. That value can be can be misleading as it also includes metadata instructions (e.g., DBG_VALUE) which have no real impact. If we do choose to keep this around, we probably should guard it by a DEBUG macro, as it's not used in production builds. Reviewers: majnemer, congh, rengolin Reviewed By: rengolin Subscribers: llvm-commits, rengolin Differential Revision: https://reviews.llvm.org/D44495 llvm-svn: 327589
* [EarlyCSE] Exploit open ended invariant.start scopesPhilip Reames2018-03-141-19/+75
| | | | | | | | | | | | If we have an invariant.start with no corresponding invariant.end, then the memory location becomes invariant indefinitely after the invariant.start. As a result, anything dominated by the start is guaranteed to see the value the memory location had when the invariant.start executed. This patch adds an AvailableInvariants table which tracks the generation a particular memory location became invariant and then uses that information to allow value forwarding that would otherwise be disallowed by potentially aliasing stores. (Reminder: In EarlyCSE everything clobbers everything by default.) This should be compatible with the MemorySSA variant, but design is generational. We can and should add first class support for invariant.start within MemorySSA at a later time. I took a quick look at doing so, but probably need some input from a MemorySSA expert. Differential Revision: https://reviews.llvm.org/D43716 llvm-svn: 327577
* Simplify more cases of logical ops of masked icmps.Hiroshi Yamauchi2018-03-131-17/+199
| | | | | | | | | | | | | | | | | | Summary: For example, ((X & 255) != 0) && ((X & 15) == 8) -> ((X & 15) == 8). ((X & 7) != 0) && ((X & 15) == 8) -> false. Reviewers: davidxl Reviewed By: davidxl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43835 llvm-svn: 327450
* Test Commit NFC. Updated commentAnna Thomas2018-03-131-1/+1
| | | | llvm-svn: 327436
* [SLP] clean some formatsHaicheng Wu2018-03-131-3/+3
| | | | llvm-svn: 327433
* [ThinLTO] Clear dllimport when setting dso_local.Rafael Espindola2018-03-131-1/+4
| | | | | | | | | | This is PR36686. If a user of a library is LTOed with that library we take the opportunity to set dso_local, but we don't clear dllimport, which creates an invalid IR. llvm-svn: 327408
* [InstCombine] fix fmul reassociation to avoid creating an extra fdivSanjay Patel2018-03-131-6/+20
| | | | | | | | | | | | | This was supposed to be an NFC refactoring that will eventually allow eliminating the isFast() predicate, but there's a rare possibility that we would pessimize the code as shown in the test case because we failed to check 'hasOneUse()' properly. This version also removes an inefficiency of the old code; we would look for: (X * C) * C1 --> X * (C * C1) ...but that pattern is always handled by SimplifyAssociativeOrCommutative(). llvm-svn: 327404
* [SROA] Take advantage of separate alignments for memcpy source and destinationDaniel Neilson2018-03-131-11/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change is part of step five in the series of changes to remove alignment argument from memcpy/memmove/memset in favour of alignment attributes. In particular, this changes the SROA pass to cease using the old getAlignment() & setAlignment() APIs of MemoryIntrinsic in favour of getting source & dest specific alignments through the new API. This allows us to enhance visitMemTransferInst to be more aggressive setting the alignment in memcpy calls that it creates, as well as to only change the alignment of a memcpy/memmove argument that it replaces. Steps: Step 1) Remove alignment parameter and create alignment parameter attributes for memcpy/memmove/memset. ( rL322965, rC322964, rL322963 ) Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing source and dest alignments. ( rL323597 ) Step 3) Update Clang to use the new IRBuilder API. ( rC323617 ) Step 4) Update Polly to use the new IRBuilder API. ( rL323618 ) Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API, and those that use use MemIntrinsicInst::[get|set]Alignment() to use [get|set]DestAlignment() and [get|set]SourceAlignment() instead. ( rL323886, rL323891, rL324148, rL324273, rL324278, rL324384, rL324395, rL324402, rL324626, rL324642, rL324653, rL324654, rL324773, rL324774, rL324781, rL324784, rL324955, rL324960, rL325816 ) Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the MemIntrinsicInst::[get|set]Alignment() methods. Reference http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html Reviewers: chandlerc, bollu, efriedma Reviewed By: efriedma Subscribers: efriedma, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D42974 llvm-svn: 327398
* [Evaluator] Evaluate load/store with bitcastEugene Leviant2018-03-131-12/+22
| | | | | | Differential revision: https://reviews.llvm.org/D43457 llvm-svn: 327381
* [MergeICmps] Make sure that the comparison only has one use.Clement Courbet2018-03-131-0/+9
| | | | | | | | | | | | Summary: Fixes PR36557. Reviewers: trentxintong, spatel Subscribers: mstorsjo, llvm-commits Differential Revision: https://reviews.llvm.org/D44083 llvm-svn: 327372
* Reland r327041: [ThinLTO] Keep available_externally symbols liveVlad Tsyrklevich2018-03-131-3/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change fixes PR36483. The bug was originally introduced by a change that marked non-prevailing symbols dead. This broke LowerTypeTests handling of available_externally functions, which are non-prevailing. LowerTypeTests uses liveness information to avoid emitting thunks for unused functions. Marking available_externally functions dead is incorrect, the functions are used though the function definitions are not. This change keeps them live, and lets the EliminateAvailableExternally/GlobalDCE passes remove them later instead. (Reland with a suspected fix for a unit test failure I haven't been able to reproduce locally) Reviewers: pcc, tejohnson Reviewed By: tejohnson Subscribers: grimar, mehdi_amini, inglorion, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D43690 llvm-svn: 327360
OpenPOWER on IntegriCloud