summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert r341269: [Constant Hoisting] Hoisting Constant GEP ExpressionsChandler Carruth2018-09-041-136/+36
| | | | | | | | | | One of the tests is failing 50% of the time when expensive checks are enabled. Not sure how deep the problem is so just reverting while the author can investigate so that the bots stop repeatedly failing and blaming things incorrectly. Will respond with details on the original commit. llvm-svn: 341365
* [x86/SLH] Add a real Clang flag and LLVM IR attribute for SpeculativeChandler Carruth2018-09-042-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Load Hardening. Wires up the existing pass to work with a proper IR attribute rather than just a hidden/internal flag. The internal flag continues to work for now, but I'll likely remove it soon. Most of the churn here is adding the IR attribute. I talked about this Kristof Beyls and he seemed at least initially OK with this direction. The idea of using a full attribute here is that we *do* expect at least some forms of this for other architectures. There isn't anything *inherently* x86-specific about this technique, just that we only have an implementation for x86 at the moment. While we could potentially expose this as a Clang-level attribute as well, that seems like a good question to defer for the moment as it isn't 100% clear whether that or some other programmer interface (or both?) would be best. We'll defer the programmer interface side of this for now, but at least get to the point where the feature can be enabled without relying on implementation details. This also allows us to do something that was really hard before: we can enable *just* the indirect call retpolines when using SLH. For x86, we don't have any other way to mitigate indirect calls. Other architectures may take a different approach of course, and none of this is surfaced to user-level flags. Differential Revision: https://reviews.llvm.org/D51157 llvm-svn: 341363
* [InstCombine] Fold icmp ugt/ult (add nuw X, C2), C --> icmp ugt/ult X, (C - C2)Nicola Zaghen2018-09-041-5/+8
| | | | | | | | | | Support for sgt/slt was added in rL294898, this adds the same cases also for unsigned compares. This is the Alive proof: https://rise4fun.com/Alive/nyY Differential Revision: https://reviews.llvm.org/D50972 llvm-svn: 341353
* [NFC] Add assert to detect LCSSA breaches earlyMax Kazantsev2018-09-041-0/+10
| | | | llvm-svn: 341347
* [IndVars] Fix usage of SCEVExpander to not mess with SCEVConstant. PR38674Max Kazantsev2018-09-041-18/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch removes the function `expandSCEVIfNeeded` which behaves not as it was intended. This function tries to make a lookup for exact existing expansion and only goes to normal expansion via `expandCodeFor` if this lookup hasn't found anything. As a result of this, if some instruction above the loop has a `SCEVConstant` SCEV, this logic will return this instruction when asked for this `SCEVConstant` rather than return a constant value. This is both non-profitable and in some cases leads to breach of LCSSA form (as in PR38674). Whether or not it is possible to break LCSSA with this algorithm and with some non-constant SCEVs is still in question, this is still being investigated. I wasn't able to construct such a test so far, so maybe this situation is impossible. If it is, it will go as a separate fix. Rather than do it, it is always correct to just invoke `expandCodeFor` unconditionally: it behaves smarter about insertion points, and as side effect of this it will choose a constant value for SCEVConstants. For other SCEVs it may end up finding a better insertion point. So it should not be worse in any case. NOTE: So far the only known case for which this transform may break LCSSA is mapping of SCEVConstant to an instruction. However there is a suspicion that the entire algorithm can compromise LCSSA form for other cases as well (yet not proved). Differential Revision: https://reviews.llvm.org/D51286 Reviewed By: etherzhhb llvm-svn: 341345
* [InstCombine] simplify xor/not folds; NFCISanjay Patel2018-09-031-22/+16
| | | | llvm-svn: 341336
* [InstCombine] allow add+not --> sub for arbitrary vector constants.Sanjay Patel2018-09-031-5/+4
| | | | llvm-svn: 341335
* [SLC] Support expanding pow(x, n+0.5) to x * x * ... * sqrt(x)Florian Hahn2018-09-031-14/+52
| | | | | | | | | | Reviewers: evandro, efriedma, spatel Reviewed By: spatel Differential Revision: https://reviews.llvm.org/D51435 llvm-svn: 341330
* Add header guards to some headers that are missing themArgyrios Kyrtzidis2018-09-031-0/+5
| | | | | | | Also adjust some of dsymutil's headers to put the header guards at the top, otherwise the compiler will not recognize them as header guards. llvm-svn: 341323
* [InstCombine] allow not+sub fold for arbitrary vector constantsSanjay Patel2018-09-021-8/+4
| | | | | | | | The fold was implemented for the general case but use-limitation, but the later constant version which didn't check uses was only matching splat constants. llvm-svn: 341292
* [Reassociate] swap binop operands to increase factoring potentialSanjay Patel2018-09-021-0/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | If we have a pair of binops feeding another pair of binops, rearrange the operands so the matching pair are together because that allows easy factorization folds to happen in instcombine: ((X << S) & Y) & (Z << S) --> ((X << S) & (Z << S)) & Y (reassociation) --> ((X & Z) << S) & Y (factorize shift from 'and' ops optimization) This is part of solving PR37098: https://bugs.llvm.org/show_bug.cgi?id=37098 Note that there's an instcombine version of this patch attached there, but we're trying to make instcombine have less responsibility to improve compile-time efficiency. For reasons I still don't completely understand, reassociate does this kind of transform sometimes, but misses everything in my motivating cases. This patch on its own is gluing an independent cleanup chunk to the end of the existing RewriteExprTree() loop. We can build on it and do something stronger to better order the full expression tree like D40049. That might be an alternative to the proposal to add a separate reassociation pass like D41574. Differential Revision: https://reviews.llvm.org/D45842 llvm-svn: 341288
* [InstCombine] simplify code for 'or' foldSanjay Patel2018-09-011-28/+13
| | | | | | | | | | | This is no-outwardly-visible-change intended, so no test. But the code is smaller and more efficient. The check for a 'not' op is intended to avoid the expensive value tracking call when it should not be necessary, and it might prevent infinite looping when we resurrect: rL300977 llvm-svn: 341280
* [Constant Hoisting] Hoisting Constant GEP ExpressionsZhaoshi Zheng2018-09-011-36/+136
| | | | | | | | | | Leverage existing logic in constant hoisting pass to transform constant GEP expressions sharing the same base global variable. Multi-dimensional GEPs are rewritten into single-dimensional GEPs. Differential Revision: https://reviews.llvm.org/D51396 llvm-svn: 341269
* SLPVectorizer: Fix assert with different sized address spacesMatt Arsenault2018-08-311-1/+1
| | | | llvm-svn: 341215
* [InstCombine] Expand the simplification of pow() into exp2()Evandro Menezes2018-08-301-5/+27
| | | | | | | | | | | | | Generalize the simplification of `pow(2.0, y)` to `pow(2.0 ** n, y)` for all scalar and vector types. This improvement helps some benchmarks in SPEC CPU2000 and CPU2006, such as 252.eon, 447.dealII, 453.povray. Otherwise, no significant regressions on x86-64 or A64. Differential revision: https://reviews.llvm.org/D49273 llvm-svn: 341095
* [SROA] Fix alignment for uses of PHI nodes.Eli Friedman2018-08-301-0/+42
| | | | | | | | | | | | Splitting an alloca can decrease the alignment of GEPs into the partition. Normally, rewriting accounts for this, but the code was missing for uses of PHI nodes and select instructions. Fixes https://bugs.llvm.org/show_bug.cgi?id=38707 . Differential Revision: https://reviews.llvm.org/D51335 llvm-svn: 341094
* [libFuzzer] Port to WindowsMatt Morehouse2018-08-301-6/+33
| | | | | | | | | | | | | | | | | | | | Summary: Port libFuzzer to windows-msvc. This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well. It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch. It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them. Patch By: metzman Reviewers: morehouse, rnk Reviewed By: morehouse, rnk Subscribers: #sanitizers, delcypher, morehouse, kcc, eraman Differential Revision: https://reviews.llvm.org/D51022 llvm-svn: 341082
* [NFC] Rename the DivergenceAnalysis to LegacyDivergenceAnalysisNicolai Haehnle2018-08-302-10/+10
| | | | | | | | | | | | | | | | | | | | Summary: This is patch 1 of the new DivergenceAnalysis (https://reviews.llvm.org/D50433). The purpose of this patch is to free up the name DivergenceAnalysis for the new generic implementation. The generic implementation class will be shared by specialized divergence analysis classes. Patch by: Simon Moll Reviewed By: nhaehnle Subscribers: jvesely, jholewinski, arsenm, nhaehnle, mgorny, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D50434 Change-Id: Ie8146b11be2c50d5312f30e11c7a3036a15b48cb llvm-svn: 341071
* Revert "[SimplifyCFG] Common debug handling [NFC]"Martin Storsjo2018-08-301-0/+8
| | | | | | | | | This reverts commit r340997. This change turned out not to be NFC after all, but e.g. causes clang to crash when building the linux kernel for aarch64. llvm-svn: 341031
* [NFC] Move OrderedInstructions and InstructionPrecedenceTracking to AnalysisMax Kazantsev2018-08-304-153/+0
| | | | | | | | These classes don't make any changes to IR and have no reason to be in Transform/Utils. This patch moves them to Analysis folder. This will allow us reusing these classes in some analyzes, like MustExecute. llvm-svn: 341015
* Re-enable "[NFC] Unify guards detection"Max Kazantsev2018-08-305-15/+12
| | | | | | | | | | rL340921 has been reverted by rL340923 due to linkage dependency from Transform/Utils to Analysis which is not allowed. In this patch this has been fixed, a new utility function moved to Analysis. Differential Revision: https://reviews.llvm.org/D51152 llvm-svn: 341014
* [SimplifyCFG] Rename a variable for readibility of a future change [NFC]Philip Reames2018-08-301-8/+9
| | | | llvm-svn: 341004
* [SimplifyCFG] Fix a cost modeling oversight in branch commoningPhilip Reames2018-08-301-2/+8
| | | | | | | | The cost modeling was not accounting for the fact we were duplicating the instruction once per predecessor. With a default threshold of 1, this meant we were actually creating #pred copies. Adding to the fun, there is *absolutely no* test coverage for this. Simply bailing for more than one predecessor passes all checked in tests. llvm-svn: 341001
* [SimplifyCFG] Common debug handling [NFC]Philip Reames2018-08-291-8/+0
| | | | llvm-svn: 340997
* Revert r340947 "[InstCombine] Expand the simplification of pow() into exp2()"Reid Kleckner2018-08-291-25/+5
| | | | | | It broke the clang-cl self-host. llvm-svn: 340991
* Add a todo and tests to Address a review commnt from D50925 [NFC]Philip Reames2018-08-291-1/+3
| | | | llvm-svn: 340978
* [LICM] Hoist stores of invariant values to invariant addresses out of loopsPhilip Reames2018-08-291-3/+23
| | | | | | | | | | | | Teach LICM to hoist stores out of loops when the store writes to a location otherwise unused in the loop, writes a value which is invariant, and is guaranteed to execute if the loop is entered. Worth noting is that this transformation is partially overlapping with the existing promotion transformation. Reasons this is worthwhile anyway include: * For multi-exit loops, this doesn't require duplication of the store. * It kicks in for case where we can't prove we exit through a normal exit (i.e. we may throw), but can prove the store executes before that possible side exit. Differential Revision: https://reviews.llvm.org/D50925 llvm-svn: 340974
* [SimpleLoopUnswitch] After unswitch delete dead blocks in parent loopsFedor Sergeev2018-08-291-2/+10
| | | | | | | | | | | | | | | | | | | | Summary: Assert from PR38737 happens on the dead block inside the parent loop after unswitching nontrivial switch in the inner loop. deleteDeadBlocksFromLoop now takes extra care to detect/remove dead blocks in all the parent loops in addition to the blocks from original loop being unswitched. Reviewers: asbirlea, chandlerc Reviewed By: asbirlea Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51415 llvm-svn: 340955
* Revert "[libFuzzer] Port to Windows"Matt Morehouse2018-08-291-33/+6
| | | | | | This reverts r340949 due to bot breakage again. llvm-svn: 340954
* [InstCombine] canonicalize fneg with llvm.sinSanjay Patel2018-08-291-5/+14
| | | | | | | | | | | | | | This is a follow-up to rL339604 which did the same transform for a sin libcall. The handling of intrinsics vs. libcalls is unfortunately scattered, so I'm just adding this next to the existing transform for llvm.cos for now. This should resolve PR38458: https://bugs.llvm.org/show_bug.cgi?id=38458 If the call was already negated, the negates will cancel each other out. llvm-svn: 340952
* [libFuzzer] Port to WindowsMatt Morehouse2018-08-291-6/+33
| | | | | | | | | | | | | | | | | | Summary: Port libFuzzer to windows-msvc. This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well. It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch. It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them. Reviewers: morehouse, rnk Reviewed By: morehouse, rnk Subscribers: #sanitizers, delcypher, morehouse, kcc, eraman Differential Revision: https://reviews.llvm.org/D51022 llvm-svn: 340949
* [InstCombine] Expand the simplification of pow() with nested exp{,2}()Evandro Menezes2018-08-291-4/+21
| | | | | | | | | | | | Expand the simplification of `pow(exp{,2}(x), y)` to all FP types. This improvement helps some benchmarks in SPEC CPU2000 and CPU2006, such as 252.eon, 447.dealII, 453.povray. Otherwise, no significant regressions on x86-64 or A64. Differential revision: https://reviews.llvm.org/D51195 llvm-svn: 340948
* [InstCombine] Expand the simplification of pow() into exp2()Evandro Menezes2018-08-291-5/+25
| | | | | | | | | | | | | Generalize the simplification of `pow(2.0, y)` to `pow(2.0 ** n, y)` for all scalar and vector types. This improvement helps some benchmarks in SPEC CPU2000 and CPU2006, such as 252.eon, 447.dealII, 453.povray. Otherwise, no significant regressions on x86-64 or A64. Differential revision: https://reviews.llvm.org/D49273 llvm-svn: 340947
* [InstCombine] Replace two calls to getNumUses() with !hasNUsesOrMoreCraig Topper2018-08-291-1/+1
| | | | | | We were calling getNumUses to check for 1 or 2 uses. But getNumUses is linear in the number of uses. We can instead use !hasNUsesOrMore(3) which will stop the linear scan as soon as it determines there are at least 3 uses even if there are more. llvm-svn: 340939
* [InstCombine] move declarations closer to uses; NFCSanjay Patel2018-08-291-5/+3
| | | | llvm-svn: 340930
* [InstCombine] remove unnecessary shuffle undef foldingSanjay Patel2018-08-291-7/+0
| | | | | | | | Add a test for constant folding to show that (shuffle undef, undef, mask) should already be handled via instsimplify. llvm-svn: 340926
* Revert r340922 "[GVNHoist] Re-enable GVNHoist by default"Alexandros Lamprineas2018-08-291-2/+2
| | | | | | | | | | Another sanitizer buildbot failed this time at bootstrap when compiling SemaTemplateInstantiate.cpp with this assertion: `dominates(MD, U) && "Memory Def does not dominate it's uses"'. http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/15047 llvm-svn: 340925
* Revert r340921 "[NFC] Unify guards detection"Hans Wennborg2018-08-296-16/+15
| | | | | | | | | | | | | | | | | | This broke the build, see e.g. http://lab.llvm.org:8011/builders/clang-cmake-armv8-lnt/builds/4626/ http://lab.llvm.org:8011/builders/clang-ppc64be-linux-lnt/builds/18647/ http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux/builds/5856/ http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/22800/ > We have multiple places in code where we try to identify whether or not > some instruction is a guard. This patch factors out this logic into a separate > utility function which works uniformly in all places. > > Differential Revision: https://reviews.llvm.org/D51152 > Reviewed By: fedor.sergeev llvm-svn: 340923
* [GVNHoist] Re-enable GVNHoist by defaultAlexandros Lamprineas2018-08-291-2/+2
| | | | | | | | | Rebase rL338240 since the excessive memory usage observed when using GVNHoist with UBSan has been fixed by rL340818. Differential Revision: https://reviews.llvm.org/D49858 llvm-svn: 340922
* [NFC] Unify guards detectionMax Kazantsev2018-08-296-15/+16
| | | | | | | | | | | We have multiple places in code where we try to identify whether or not some instruction is a guard. This patch factors out this logic into a separate utility function which works uniformly in all places. Differential Revision: https://reviews.llvm.org/D51152 Reviewed By: fedor.sergeev llvm-svn: 340921
* [NFC] Factor out guard utility methods into a separate fileMax Kazantsev2018-08-293-48/+67
| | | | | | | | | | This patch creates file GuardUtils which will contain logic for work with guards that can be shared across different passes. Differential Revision: https://reviews.llvm.org/D51151 Reviewed By: fedor.sergeev llvm-svn: 340914
* LoopSink: Don't sink into blocks without an insertion point (PR38462)Hans Wennborg2018-08-291-0/+8
| | | | | | | | | In the PR, LoopSink was trying to sink into a catchswitch block, which doesn't have a valid insertion point. Differential Revision: https://reviews.llvm.org/D51307 llvm-svn: 340900
* [QTOOL-37352] Consider isLegalAddressingImm in Constant HoistingZhaoshi Zheng2018-08-281-1/+21
| | | | | | | | | | | | | | In Thumb1, legal imm range is [0, 255] for ADD/SUB instructions. However, the legal imm range for LD/ST in (R+Imm) addressing mode is [0, 127]. Imms in [128, 255] are materialized by mov R, #imm, and LD/STs use them in (R+R) addressing mode. This patch checks if a constant is used as offset in (R+Imm), if so, it checks isLegalAddressingMode passing the constant value as BaseOffset. Differential Revision: https://reviews.llvm.org/D50931 llvm-svn: 340882
* [SimpleLoopUnswitch] Form dedicated exits after trivial unswitches.Alina Sbirlea2018-08-281-5/+8
| | | | | | | | | | | | | | Summary: Form dedicated exits after trivial unswitches. Fixes PR38737, PR38283. Reviewers: chandlerc, fedor.sergeev Subscribers: sanjoy, jlebar, uabelho, llvm-commits Differential Revision: https://reviews.llvm.org/D51375 llvm-svn: 340871
* Revert "[libFuzzer] Port to Windows"Matt Morehouse2018-08-281-23/+6
| | | | | | This reverts commit r340860 due to failing tests. llvm-svn: 340867
* [libFuzzer] Port to WindowsMatt Morehouse2018-08-281-6/+23
| | | | | | | | | | | | | | | | | | | | Summary: Port libFuzzer to windows-msvc. This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well. It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch. It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them. Patch By: metzman Reviewers: morehouse, rnk Reviewed By: morehouse, rnk Subscribers: morehouse, kcc, eraman Differential Revision: https://reviews.llvm.org/D51022 llvm-svn: 340860
* AMDGPU: Remove nan tests in class if src is nnanMatt Arsenault2018-08-281-0/+7
| | | | llvm-svn: 340850
* [Inliner] Attribute callsites with inline remarksDavid Bolvansky2018-08-281-10/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Sometimes reading an output *.ll file it is not easy to understand why some callsites are not inlined. We can read output of inline remarks (option --pass-remarks-missed=inline) and try correlating its messages with the callsites. An easier way proposed by this patch is to add to every callsite processed by Inliner an attribute with the latest message that describes the cause of not inlining this callsite. The attribute is called //inline-remark//. By default this feature is off. It can be switched on by the option //-inline-remark-attribute//. For example in the provided test the result method //@test1// has two callsites //@bar// and inline remarks report different inlining missed reasons: remark: <unknown>:0:0: bar not inlined into test1 because too costly to inline (cost=-5, threshold=-6) remark: <unknown>:0:0: bar not inlined into test1 because it should never be inlined (cost=never): recursive It is not clear which remark correspond to which callsite. With the inline remark attribute enabled we get the reasons attached to their callsites: define void @test1() { call void @bar(i1 true) #0 call void @bar(i1 false) #2 ret void } attributes #0 = { "inline-remark"="(cost=-5, threshold=-6)" } .. attributes #2 = { "inline-remark"="(cost=never): recursive" } Patch by: yrouban (Yevgeny Rouban) Reviewers: xbolva00, tejohnson, apilipenko Reviewed By: xbolva00, tejohnson Subscribers: eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D50435 llvm-svn: 340834
* [CloneFunction] Constant fold terminators before checking single predecessorMikael Holmen2018-08-281-7/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This fixes PR31105. There is code trying to delete dead code that does so by e.g. checking if the single predecessor of a block is the block itself. That check fails on a block like this bb: br i1 undef, label %bb, label %bb since that has two (identical) predecessors. However, after the check for dead blocks there is a call to ConstantFoldTerminator on the basic block, and that call simplifies the block to bb: br label %bb Therefore we now do the call to ConstantFoldTerminator before the check if the block is dead, so it can realize that it really is. The original behavior lead to the block not being removed, but it was simplified as above, and then we did a call to Dest->replaceAllUsesWith(&*I); with old and new being equal, and an assertion triggered. Reviewers: chandlerc, fhahn Reviewed By: fhahn Subscribers: eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D51280 llvm-svn: 340820
* [GVNHoist] Prune out useless CHI insertionsAlexandros Lamprineas2018-08-281-2/+5
| | | | | | | | | | Fix for the out-of-memory error when compiling SemaChecking.cpp with GVNHoist and ubsan enabled. I've used a cache for inserted CHIs to avoid excessive memory usage. Differential Revision: https://reviews.llvm.org/D50323 llvm-svn: 340818
OpenPOWER on IntegriCloud