aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Analysis/StackSafetyAnalysis.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-04-21[LLVM] Cleanup pass initialization for Analysis passes (#135858)Rahul Joshi1-7/+2
- Do not call pass initialization from pass constructors. - Instead, pass initialization should happen in the `initializeAnalysis` function. - https://github.com/llvm/llvm-project/issues/111767
2025-03-25[Analysis] Use *Set::insert_range (NFC) (#132878)Kazu Hirata1-2/+1
We can use *Set::insert_range to collapse: for (auto Elem : Range) Set.insert(E); down to: Set.insert_range(Range); In some cases, we can further fold that into the set declaration.
2024-10-29[StackSafetyAnalysis] Bail out when calling ifuncFangrui Song1-1/+1
An assertion failure arises when a call instruction calls a GlobalIFunc. Since we cannot reason about the underlying function, just bail out. Fix #87923 Pull Request: https://github.com/llvm/llvm-project/pull/113841
2024-06-28[IR] Add getDataLayout() helpers to Function and GlobalValue (#96919)Nikita Popov1-2/+2
Similar to https://github.com/llvm/llvm-project/pull/96902, this adds `getDataLayout()` helpers to Function and GlobalValue, replacing the current `getParent()->getDataLayout()` pattern.
2024-06-27[IR] Add getDataLayout() helpers to BasicBlock and Instruction (#96902)Nikita Popov1-1/+1
This is a helper to avoid writing `getModule()->getDataLayout()`. I regularly try to use this method only to remember it doesn't exist... `getModule()->getDataLayout()` is also a common (the most common?) reason why code has to include the Module.h header.
2024-06-14[llvm] Use llvm::unique (NFC) (#95628)Kazu Hirata1-1/+1
2024-01-30[StackSafetyAnalysis] Don't call getTruncateOrZeroExtend for pointers of ↵Pierre van Houtryve1-9/+31
different sizes (#79804) Otherwise SCEV asserts `Can't extend pointer!` Fixes SWDEV-442670
2024-01-11[StackSafetyAnalysis] Bail out if MemIntrinsic length is -1 (#77837)Fangrui Song1-1/+1
Clang generates llvm.memset.p0.i64 with a length of -1 for the following code in `-stdlib=libc++ -std=c++20` mode (https://github.com/llvm/llvm-project/pull/77210#issuecomment-1887650010) ```cpp bool strtof_clamp(const std::string &str); void floatsuffix_check(char *yytext_r) { std::string text = yytext_r; text.resize(text.size() - 1); strtof_clamp(text); } ``` `Sizes = [0xffffffffffffffff, 0)`. `SizeRange = [0, 0-1)`, leading to `assert(!isUnsafe(SizeRange));` failure. Bail out if the length is -1. Other negative values are handled by the existing condition.
2023-11-07[NFC] Remove Type::getInt8PtrTy (#71029)Paulo Matos1-2/+2
Replace this with PointerType::getUnqual(). Followup to the opaque pointer transition. Fixes an in-code TODO item.
2023-08-31Support atomic write operations in stack safetyFlorian Mayer1-16/+27
This has two benefits: * we can now mark allocas that are used in atomic operations as safe * this fixes a bug that would incorrectly mark all atomic writes as safe in HWASan instrumentation. this is because stack safety keeps a list of all *unsafe* operations that are reachable from an alloca, but it did not analyze atomic writes, so it would always mark them as safe. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D159153
2023-01-11[NFC] Use TypeSize::geFixedValue() instead of TypeSize::getFixedSize()Guillaume Chatelet1-3/+3
This change is one of a series to implement the discussion from https://reviews.llvm.org/D141134.
2022-07-16[Analysis] Qualify auto variables in for loops (NFC)Kazu Hirata1-10/+10
2022-06-18[llvm] Use value_or instead of getValueOr (NFC)Kazu Hirata1-2/+2
2022-03-01Cleanup includes: LLVMAnalysisserge-sans-paille1-1/+0
Number of lines output by preprocessor: before: 1065940348 after: 1065307662 Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.llvm.org/D120659
2021-11-23[stack-safety] Check SCEV constraints at memory instructions.Florian Mayer1-31/+95
Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D113160
2021-10-18[Sanitizers] Replaced getMaxPointerSizeInBits with getPointerSizeInBits, ↵Kirill Stoimenov1-5/+3
which was causing failures for 32bit x86. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D111829
2021-10-06[IR][NFC] Rename getBaseObject to getAliaseeObjectItay Bookstein1-1/+1
To better reflect the meaning of the now-disambiguated {GlobalValue, GlobalAlias}::getBaseObject after breaking off GlobalIFunc::getResolverFunction (D109792), the function is renamed to getAliaseeObject.
2021-09-22[hwasan] also omit safe mem[cpy|mov|set].Florian Mayer1-10/+12
Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D109816
2021-09-19[llvm] Use pop_back_val (NFC)Kazu Hirata1-2/+1
2021-09-13[hwasan] Respect returns attribute when tracking values.Florian Mayer1-0/+5
Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D109233
2021-09-10[stack-safety] Allow to determine safe accesses.Florian Mayer1-10/+37
Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D109503
2021-09-09[APInt] Normalize naming on keep constructors / predicate methods.Chris Lattner1-5/+4
This renames the primary methods for creating a zero value to `getZero` instead of `getNullValue` and renames predicates like `isAllOnesValue` to simply `isAllOnes`. This achieves two things: 1) This starts standardizing predicates across the LLVM codebase, following (in this case) ConstantInt. The word "Value" doesn't convey anything of merit, and is missing in some of the other things. 2) Calling an integer "null" doesn't make any sense. The original sin here is mine and I've regretted it for years. This moves us to calling it "zero" instead, which is correct! APInt is widely used and I don't think anyone is keen to take massive source breakage on anything so core, at least not all in one go. As such, this doesn't actually delete any entrypoints, it "soft deprecates" them with a comment. Included in this patch are changes to a bunch of the codebase, but there are more. We should normalize SelectionDAG and other APIs as well, which would make the API change more mechanical. Differential Revision: https://reviews.llvm.org/D109483
2021-09-09[NFC] [stack-safety] add placeholder addRange.Florian Mayer1-14/+19
This is in preparataion of D108457.
2021-09-09[stack-safety] [NFC] do not terminate print with blank line.Florian Mayer1-2/+3
2021-09-09[NFC] [stack-safety] remove unused return value.Florian Mayer1-11/+9
2021-07-06Recommit [ScalarEvolution] Make getMinusSCEV() fail for unrelated pointers.Eli Friedman1-0/+2
As part of making ScalarEvolution's handling of pointers consistent, we want to forbid multiplying a pointer by -1 (or any other value). This means we can't blindly subtract pointers. There are a few ways we could deal with this: 1. We could completely forbid subtracting pointers in getMinusSCEV() 2. We could forbid subracting pointers with different pointer bases (this patch). 3. We could try to ptrtoint pointer operands. The option in this patch is more friendly to non-integral pointers: code that works with normal pointers will also work with non-integral pointers. And it seems like there are very few places that actually benefit from the third option. As a minimal patch, the ScalarEvolution implementation of getMinusSCEV still ends up subtracting pointers if they have the same base. This should eliminate the shared pointer base, but eventually we'll need to rewrite it to avoid negating the pointer base. I plan to do this as a separate step to allow measuring the compile-time impact. This doesn't cause obvious functional changes in most cases; the one case that is significantly affected is ICmpZero handling in LSR (which is the source of almost all the test changes). The resulting changes seem okay to me, but suggestions welcome. As an alternative, I tried explicitly ptrtoint'ing the operands, but the result doesn't seem obviously better. I deleted the test lsr-undef-in-binop.ll becuase I couldn't figure out how to repair it to test what it was actually trying to test. Recommitting with fix to MemoryDepChecker::isDependent. Differential Revision: https://reviews.llvm.org/D104806
2021-07-06Revert "[ScalarEvolution] Make getMinusSCEV() fail for unrelated pointers."Eli Friedman1-2/+0
This reverts commit 74d6ce5d5f169e9cf3fac0eb1042602e286dd2b9. Seeing crashes on buildbots in MemoryDepChecker::isDependent.
2021-07-06[ScalarEvolution] Make getMinusSCEV() fail for unrelated pointers.Eli Friedman1-0/+2
As part of making ScalarEvolution's handling of pointers consistent, we want to forbid multiplying a pointer by -1 (or any other value). This means we can't blindly subtract pointers. There are a few ways we could deal with this: 1. We could completely forbid subtracting pointers in getMinusSCEV() 2. We could forbid subracting pointers with different pointer bases (this patch). 3. We could try to ptrtoint pointer operands. The option in this patch is more friendly to non-integral pointers: code that works with normal pointers will also work with non-integral pointers. And it seems like there are very few places that actually benefit from the third option. As a minimal patch, the ScalarEvolution implementation of getMinusSCEV still ends up subtracting pointers if they have the same base. This should eliminate the shared pointer base, but eventually we'll need to rewrite it to avoid negating the pointer base. I plan to do this as a separate step to allow measuring the compile-time impact. This doesn't cause obvious functional changes in most cases; the one case that is significantly affected is ICmpZero handling in LSR (which is the source of almost all the test changes). The resulting changes seem okay to me, but suggestions welcome. As an alternative, I tried explicitly ptrtoint'ing the operands, but the result doesn't seem obviously better. I deleted the test lsr-undef-in-binop.ll becuase I couldn't figure out how to repair it to test what it was actually trying to test. Differential Revision: https://reviews.llvm.org/D104806
2021-01-09[llvm] Drop unnecessary make_range (NFC)Kazu Hirata1-1/+1
2020-10-03[Analysis] resolveAllCalls - fix use after std::move warning. NFCI.Simon Pilgrim1-1/+4
We can't use Use.Calls after its std::move()'d to TmpCalls as it will be in an undefined state. Instead, swap with the known empty map in TmpCalls so we can then safely emplace_back into the now empty Use.Calls. Fixes clang static analyzer warning.
2020-09-18[NFC][StackSafety] Replace auto with typeVitaly Buka1-3/+4
Fixes static analyzer is warning.
2020-08-17[NFC][StackSafety] Move out sort from the loopVitaly Buka1-4/+6
2020-08-16[StackSafety] Change how callee searched in indexVitaly Buka1-16/+48
Handle other than local linkage types.
2020-08-14[StackSafety] Use ValueInfo in ParamAccess::CallVitaly Buka1-2/+4
This avoid GUID lookup in Index.findSummaryInModule. Follow up for D81242. Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D85269
2020-08-14Revert "[NFC][StackSafety] Move out sort from the loop"Matt Morehouse1-4/+4
This reverts commit 0426e28419799c35cf52fe3d773c5bab9928c699 due to ASan buildbot failure.
2020-08-14[NFC][StackSafety] Change map key comparisonVitaly Buka1-1/+1
2020-08-14[NFC][StackSafety] Move out sort from the loopVitaly Buka1-4/+4
2020-08-14[NFC][StackSafety] Dedup calleesVitaly Buka1-37/+50
2020-08-09[NFC][StackSafety] Add a couple of early returnsVitaly Buka1-2/+3
2020-08-09[NFC][StackSafety] Count dataflow inputsVitaly Buka1-0/+3
2020-08-09[StackSafety] Fix union which produces wrapped setsVitaly Buka1-18/+28
2020-08-09[NFC][StackSafety] Avoid assert in getBaseObjecVitaly Buka1-1/+1
2020-08-09[StackSafety] Don't keep FullSet in indexVitaly Buka1-0/+3
Optimization. Missing record is enterpreted as FullSet anyway.
2020-08-07[NFC][StackSafety] Fix statisticsVitaly Buka1-2/+2
2020-08-07[StackSafety,NFC] Add Stats countersVitaly Buka1-0/+18
2020-08-06[StackSafety,NFC] Fix tests in debugVitaly Buka1-1/+0
2020-08-06[StackSafety,NFC] Add debug countersVitaly Buka1-1/+15
2020-08-06[StackSafety,NFC] Use CHECK-EMPTY in testsVitaly Buka1-0/+1
2020-08-06[LTO,NFC] Skip generateParamAccessSummary when emptyVitaly Buka1-0/+2
addGlobalValueSummary can check newly added FunctionSummary and set HasParamAccess to mark that generateParamAccessSummary is needed. Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D85182
2020-08-02[StackSafety, NFC] Don't insert empty objects into the mapVitaly Buka1-1/+1
Result should be the same but it makes generateParamAccessSummary 5x faster.
generated by cgit v1.1 at 2025-09-28 23:01:24 +0000