aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/SafeStack.cpp
AgeCommit message (Collapse)AuthorFilesLines
2024-11-12[CodeGen] Remove unused includes (NFC) (#115996)Kazu Hirata1-1/+0
Identified with misc-include-cleaner.
2024-11-04SafeStack: Respect alloca addrspace (#112536)Matt Arsenault1-2/+3
Just insert addrspacecast in cases where the alloca uses a different address space, since I don't know what else you could possibly do.
2024-11-01[llvm][NFC] Fix typos: replace “avaliable” with “available” across ↵Wang Qiang1-1/+1
various files (#114524) This pull request corrects multiple occurrences of the typo "avaliable" to "available" across the LLVM and Clang codebase. These changes improve the clarity and accuracy of comments and documentation. Specific modifications are in the following files: 1. clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp: Updated comments in readability checks for cognitive complexity. 2. llvm/include/llvm/ExecutionEngine/Orc/ExecutionUtils.h: Corrected documentation for JITDylib responsibilities. 3. llvm/include/llvm/Target/TargetMacroFusion.td: Fixed descriptions for FusionPredicate variables. 4. llvm/lib/CodeGen/SafeStack.cpp: Improved comments on DominatorTree availability. 5. llvm/lib/Target/RISCV/RISCVSchedSiFive7.td: Enhanced resource usage descriptions for vector units. 6. llvm/lib/Transforms/Scalar/LoopIdiomRecognize.cpp: Updated invariant description in shift-detect idiom logic. 7. llvm/test/MC/ARM/mve-fp-registers.s: Amended ARM MVE register availability notes. 8. mlir/lib/Bytecode/Reader/BytecodeReader.cpp: Adjusted forward reference descriptions for bytecode reader operations. These changes have no impact on code functionality, focusing solely on documentation clarity. Co-authored-by: wangqiang <wangqiang1@kylinos.cn>
2024-10-16[LLVM] Make more use of IRBuilder::CreateIntrinsic. NFC. (#112546)Jay Foad1-2/+1
Convert almost every instance of: CreateCall(Intrinsic::getOrInsertDeclaration(...), ...) to the equivalent CreateIntrinsic call.
2024-10-11[NFC] Rename `Intrinsic::getDeclaration` to `getOrInsertDeclaration` (#111752)Rahul Joshi1-1/+2
Rename the function to reflect its correct behavior and to be consistent with `Module::getOrInsertFunction`. This is also in preparation of adding a new `Intrinsic::getDeclaration` that will have behavior similar to `Module::getFunction` (i.e, just lookup, no creation).
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-24Revert "[IR][NFC] Update IRBuilder to use InsertPosition (#96497)"Stephen Tozer1-1/+1
Reverts the above commit, as it updates a common header function and did not update all callsites: https://lab.llvm.org/buildbot/#/builders/29/builds/382 This reverts commit 6481dc57612671ebe77fe9c34214fba94e1b3b27.
2024-06-24[IR][NFC] Update IRBuilder to use InsertPosition (#96497)Stephen Tozer1-1/+1
Uses the new InsertPosition class (added in #94226) to simplify some of the IRBuilder interface, and removes the need to pass a BasicBlock alongside a BasicBlock::iterator, using the fact that we can now get the parent basic block from the iterator even if it points to the sentinel. This patch removes the BasicBlock argument from each constructor or call to setInsertPoint. This has no functional effect, but later on as we look to remove the `Instruction *InsertBefore` argument from instruction-creation (discussed [here](https://discourse.llvm.org/t/psa-instruction-constructors-changing-to-iterator-only-insertion/77845)), this will simplify the process by allowing us to deprecate the InsertPosition constructor directly and catch all the cases where we use instructions rather than iterators.
2024-01-12[IRBuilder] Add CreatePtrAdd() method (NFC) (#77582)Nikita Popov1-12/+10
This abstracts over the common pattern of creating a gep with i8 element type.
2023-12-01Reland "[CodeGen] Port SafeStack to new pass manager (#74027)paperchalice1-0/+37
Forgot to update related code in `CodeGenPassBuilder.h`, also update it for `CallBrPreparePass`. Fix build when `LLVM_ENABLE_MODULES:BOOL=ON`.
2023-11-30Revert "[CodeGen] Port SafeStack to new pass manager (#73747)" (#73965)Shubham Sandeep Rastogi1-37/+0
This reverts commit a4d5fd4d2ee9470e55345a9540f6b6fb6faf66e1. The above commit breaks greendragon lldb bots: Link to failing builds: https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/63300/ https://green.lab.llvm.org/green/view/LLDB/job/as-lldb-cmake/10345/ I found this PR to be the offending one after using git bisect with the cmake invocation: cmake -G Ninja ../llvm -DCMAKE_BUILD_TYPE=Release -DCMAKE_EXPORT_COMPILE_COMMANDS=ON '-DLLVM_TARGETS_TO_BUILD=X86;ARM;AArch64' -DLLVM_ENABLE_ASSERTIONS:BOOL=TRUE -DLLVM_ENABLE_MODULES=On -DLLVM_ENABLE_PROJECTS='clang;lld;lldb;cross-project-tests' -DLLVM_VERSION_PATCH=99 '-DLLVM_ENABLE_RUNTIMES=libcxx;libcxxabi;compiler-rt' and running ninja lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/CodeGenPassBuilder.cpp.o
2023-11-30[CodeGen] Port SafeStack to new pass manager (#73747)paperchalice1-0/+37
Just copy the `runOnFunction` method from `SafeStackLegacyPass` and remove the workaround for computing analysis lazily, the analysis result in new pass manager is computed lazily by default.
2023-11-29[llvm] Replace uses of Type::getPointerTo (NFC)Youngsuk Kim1-1/+1
Work towards removing method Type::getPointerTo. Opaque ptr cleanup effort.
2023-11-07[NFC] Remove Type::getInt8PtrTy (#71029)Paulo Matos1-1/+1
Replace this with PointerType::getUnqual(). Followup to the opaque pointer transition. Fixes an in-code TODO item.
2022-11-26[CodeGen] Use std::optional in SafeStack.cpp (NFC)Kazu Hirata1-1/+2
This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-11-21Don't use Optional::getPointer (NFC)Kazu Hirata1-1/+1
Since std::optional does not offer getPointer(), this patch replaces X.getPointer() with &*X to make the migration from llvm::Optional to std::optional easier. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 Differential Revision: https://reviews.llvm.org/D138466
2022-07-17[CodeGen] Qualify auto variables in for loops (NFC)Kazu Hirata1-2/+2
2022-06-14[NFC][Alignment] Use Align in SafeStackGuillaume Chatelet1-7/+6
2022-04-20[safestack] Support safestack in stack size diagnosticsPaul Kirth1-0/+8
Current stack size diagnostics ignore the size of the unsafe stack. This patch attaches the size of the static portion of the unsafe stack to the function as metadata, which can be used by the backend to emit diagnostics regarding stack usage. Reviewed By: phosek, mcgrathr Differential Revision: https://reviews.llvm.org/D119996
2022-04-08[SafeStack] Don't create SCEV min between pointer and integer (PR54784)Nikita Popov1-20/+11
Rather than rewriting the alloca pointer to zero, use removePointerBase() to drop the base pointer. This will simply bail if the base pointer is not the alloca. We could try doing something more fancy here (like dropping the sources not based on the alloca on the premise that they aren't SafeStack-relevant), but I don't think that's worthwhile. Fixes https://github.com/llvm/llvm-project/issues/54784. Differential Revision: https://reviews.llvm.org/D123309
2022-03-16Cleanup codegen includesserge-sans-paille1-2/+0
This is a (fixed) recommit of https://reviews.llvm.org/D121169 after: 1061034926 before: 1063332844 Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.llvm.org/D121681
2022-03-10Revert "Cleanup codegen includes"Nico Weber1-0/+2
This reverts commit 7f230feeeac8a67b335f52bd2e900a05c6098f20. Breaks CodeGenCUDA/link-device-bitcode.cu in check-clang, and many LLVM tests, see comments on https://reviews.llvm.org/D121169
2022-03-10Cleanup codegen includesserge-sans-paille1-2/+0
after: 1061034926 before: 1063332844 Differential Revision: https://reviews.llvm.org/D121169
2022-03-08SafeStack: Re-enable SafeStack coloring optimizationTom Stellard1-2/+1
This was disabled in 2acea2786b9fd40e1aba018b165834168535e164 as a work-around for Issue #31491. I've reduced the test case from that bug and confirmed that it is now fixed. Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D120866
2021-12-15[SafeStack] Use Align instead of uint64_tArthur Eubanks1-9/+9
It is better typed, and the calls to getAlignment() are deprecated. Differential Revision: https://reviews.llvm.org/D115466
2021-11-01[CodeGen] Use make_early_inc_range (NFC)Kazu Hirata1-3/+2
2021-10-06Reland [IR] Increase max alignment to 4GBArthur Eubanks1-11/+12
Currently the max alignment representable is 1GB, see D108661. Setting the align of an object to 4GB is desirable in some cases to make sure the lower 32 bits are clear which can be used for some optimizations, e.g. https://crbug.com/1016945. This uses an extra bit in instructions that carry an alignment. We can store 15 bits of "free" information, and with this change some instructions (e.g. AtomicCmpXchgInst) use 14 bits. We can increase the max alignment representable above 4GB (up to 2^62) since we're only using 33 of the 64 values, but I've just limited it to 4GB for now. The one place we have to update the bitcode format is for the alloca instruction. It stores its alignment into 5 bits of a 32 bit bitfield. I've added another field which is 8 bits and should be future proof for a while. For backward compatibility, we check if the old field has a value and use that, otherwise use the new field. Updating clang's max allowed alignment will come in a future patch. Reviewed By: hans Differential Revision: https://reviews.llvm.org/D110451
2021-10-06Revert "Reland [IR] Increase max alignment to 4GB"Arthur Eubanks1-5/+6
This reverts commit 8d64314ffea55f2ad94c1b489586daa8ce30f451.
2021-10-06Reland [IR] Increase max alignment to 4GBArthur Eubanks1-6/+5
Currently the max alignment representable is 1GB, see D108661. Setting the align of an object to 4GB is desirable in some cases to make sure the lower 32 bits are clear which can be used for some optimizations, e.g. https://crbug.com/1016945. This uses an extra bit in instructions that carry an alignment. We can store 15 bits of "free" information, and with this change some instructions (e.g. AtomicCmpXchgInst) use 14 bits. We can increase the max alignment representable above 4GB (up to 2^62) since we're only using 33 of the 64 values, but I've just limited it to 4GB for now. The one place we have to update the bitcode format is for the alloca instruction. It stores its alignment into 5 bits of a 32 bit bitfield. I've added another field which is 8 bits and should be future proof for a while. For backward compatibility, we check if the old field has a value and use that, otherwise use the new field. Updating clang's max allowed alignment will come in a future patch. Reviewed By: hans Differential Revision: https://reviews.llvm.org/D110451
2021-10-06Revert "[IR] Increase max alignment to 4GB"Arthur Eubanks1-5/+6
This reverts commit df84c1fe78130a86445d57563dea742e1b85156a. Breaks some bots
2021-10-06[IR] Increase max alignment to 4GBArthur Eubanks1-6/+5
Currently the max alignment representable is 1GB, see D108661. Setting the align of an object to 4GB is desirable in some cases to make sure the lower 32 bits are clear which can be used for some optimizations, e.g. https://crbug.com/1016945. This uses an extra bit in instructions that carry an alignment. We can store 15 bits of "free" information, and with this change some instructions (e.g. AtomicCmpXchgInst) use 14 bits. We can increase the max alignment representable above 4GB (up to 2^62) since we're only using 33 of the 64 values, but I've just limited it to 4GB for now. The one place we have to update the bitcode format is for the alloca instruction. It stores its alignment into 5 bits of a 32 bit bitfield. I've added another field which is 8 bits and should be future proof for a while. For backward compatibility, we check if the old field has a value and use that, otherwise use the new field. Updating clang's max allowed alignment will come in a future patch. Reviewed By: hans Differential Revision: https://reviews.llvm.org/D110451
2021-05-31[OpaquePtr] Clean up some uses of Type::getPointerElementType()Arthur Eubanks1-4/+3
These depend on pointee types.
2021-05-30[SafeStack] Use proper API to get stack guardPengxuan Zheng1-3/+7
Using the proper API automatically sets `__stack_chk_guard` to `dso_local` if `Reloc::Static`. This wasn't strictly necessary until recently when dso_local was no longer implied by `TargetMachine::shouldAssumeDSOLocal` for `__stack_chk_guard`. By using the proper API, we can avoid generating unnecessary GOT relocations. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D102646
2021-01-27[CodeGen] SafeStack: preserve DominatorTree if it is avaliableRoman Lebedev1-11/+33
While this is mostly NFC right now, because only ARM happens to run this pass with DomTree available before it, and required after it, more backends will be affected once the SimplifyCFG's switch for domtree preservation is flipped, and DwarfEHPrepare also preserves the domtree.
2020-12-11Migrate deprecated DebugLoc::get to DILocation::getFangrui Song1-1/+2
This migrates all LLVM (except Kaleidoscope and CodeGen/StackProtector.cpp) DebugLoc::get to DILocation::get. The CodeGen/StackProtector.cpp usage may have a nullptr Scope and can trigger an assertion failure, so I don't migrate it. Reviewed By: #debug-info, dblaikie Differential Revision: https://reviews.llvm.org/D93087
2020-11-10[SafeStack] Make sure SafeStack does not break musttail call contractXun Li1-16/+16
SafeStack instrumentation should not insert anything inbetween musttail call and return instruction. For every ReturnInst that needs to be instrumented, we adjust the insertion point to the musttail call if exists. Differential Revision: https://reviews.llvm.org/D90702
2020-06-18[StackSafety] Add "Must Live" logicVitaly Buka1-1/+1
Summary: Extend StackLifetime with option to calculate liveliness where alloca is only considered alive on basic block entry if all non-dead predecessors had it alive at terminators. Depends on D82043. Reviewers: eugenis Reviewed By: eugenis Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D82124
2020-06-17[SafeStack,NFC] Fix names after files moveVitaly Buka1-2/+2
Summary: Depends on D81831. Reviewers: eugenis, pcc Reviewed By: eugenis Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D81832
2020-06-17[SafeStack,NFC] Move SafeStackColoring codeVitaly Buka1-1/+1
Summary: This code is going to be used in StackSafety. This patch is file move with minimal changes. Identifiers will be fixed in the followup patch. Reviewers: eugenis, pcc Reviewed By: eugenis Subscribers: mgorny, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D81831
2020-06-14[SafeStack,NFC] Make StackColoring read-onlyVitaly Buka1-1/+8
Move core which removes markers out of StackColoring.
2020-06-14[SafeStack,NFC] Cleanup LiveRange interfaceVitaly Buka1-1/+1
2020-06-14[SafeStack,NFC] Move ClColoring into SafeStack.cppVitaly Buka1-2/+10
This allows to reuse the code in other components.
2020-04-13[llvm][NFC] CallSite removal from inliner-related filesMircea Trofin1-14/+13
Summary: This removes CallSite from inliner files. Some dependencies where thus affected. Reviewers: dblaikie, davidxl, craig.topper Subscribers: arsenm, jvesely, nhaehnle, eraman, hiraditya, aheejin, kerbowa, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D77991
2020-02-13[Local] Do not move around dbg.declares during replaceDbgDeclareVedant Kumar1-5/+4
replaceDbgDeclare is used to update the descriptions of stack variables when they are moved (e.g. by ASan or SafeStack). A side effect of replaceDbgDeclare is that it moves dbg.declares around in the instruction stream (typically by hoisting them into the entry block). This behavior was introduced in llvm/r227544 to fix an assertion failure (llvm.org/PR22386), but no longer appears to be necessary. Hoisting a dbg.declare generally does not create problems. Usually, dbg.declare either describes an argument or an alloca in the entry block, and backends have special handling to emit locations for these. In optimized builds, LowerDbgDeclare places dbg.values in the right spots regardless of where the dbg.declare is. And no one uses replaceDbgDeclare to handle things like VLAs. However, there doesn't seem to be a positive case for moving dbg.declares around anymore, and this reordering can get in the way of understanding other bugs. I propose getting rid of it. Testing: stage2 RelWithDebInfo sanitized build, check-llvm rdar://59397340 Differential Revision: https://reviews.llvm.org/D74517
2020-01-15[NFC] Refactor InlineResult for readabilityMircea Trofin1-1/+2
Summary: InlineResult is used both in APIs assessing whether a call site is inlinable (e.g. llvm::isInlineViable) as well as in the function inlining utility (llvm::InlineFunction). It means slightly different things (can/should inlining happen, vs did it happen), and the implicit casting may introduce ambiguity (casting from 'false' in InlineFunction will default a message about hight costs, which is incorrect here). The change renames the type to a more generic name, and disables implicit constructors. Reviewers: eraman, davidxl Reviewed By: davidxl Subscribers: kerbowa, arsenm, jvesely, nhaehnle, eraman, hiraditya, haicheng, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72744
2019-12-17Resubmit "[Alignment][NFC] Deprecate CreateMemCpy/CreateMemMove"Guillaume Chatelet1-2/+2
Summary: This is a resubmit of D71473. This patch introduces a set of functions to enable deprecation of IRBuilder functions without breaking out of tree clients. Functions will be deprecated one by one and as in tree code is cleaned up. This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: aaron.ballman, courbet Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71547
2019-12-16Revert "[Alignment][NFC] Deprecate CreateMemCpy/CreateMemMove"Guillaume Chatelet1-2/+2
This reverts commit 181ab91efc9fb08dedda10a2fbc5fccb83ce8799.
2019-12-16[Alignment][NFC] Deprecate CreateMemCpy/CreateMemMoveGuillaume Chatelet1-2/+2
Summary: This patch introduces a set of functions to enable deprecation of IRBuilder functions without breaking out of tree clients. Functions will be deprecated one by one and as in tree code is cleaned up. This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: arsenm, jvesely, nhaehnle, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71473
2019-11-13Sink all InitializePasses.h includesReid Kleckner1-1/+2
This file lists every pass in LLVM, and is included by Pass.h, which is very popular. Every time we add, remove, or rename a pass in LLVM, it caused lots of recompilation. I found this fact by looking at this table, which is sorted by the number of times a file was changed over the last 100,000 git commits multiplied by the number of object files that depend on it in the current checkout: recompiles touches affected_files header 342380 95 3604 llvm/include/llvm/ADT/STLExtras.h 314730 234 1345 llvm/include/llvm/InitializePasses.h 307036 118 2602 llvm/include/llvm/ADT/APInt.h 213049 59 3611 llvm/include/llvm/Support/MathExtras.h 170422 47 3626 llvm/include/llvm/Support/Compiler.h 162225 45 3605 llvm/include/llvm/ADT/Optional.h 158319 63 2513 llvm/include/llvm/ADT/Triple.h 140322 39 3598 llvm/include/llvm/ADT/StringRef.h 137647 59 2333 llvm/include/llvm/Support/Error.h 131619 73 1803 llvm/include/llvm/Support/FileSystem.h Before this change, touching InitializePasses.h would cause 1345 files to recompile. After this change, touching it only causes 550 compiles in an incremental rebuild. Reviewers: bkramer, asbirlea, bollu, jdoerfert Differential Revision: https://reviews.llvm.org/D70211
2019-09-07Change TargetLibraryInfo analysis passes to always require FunctionTeresa Johnson1-1/+1
Summary: This is the first change to enable the TLI to be built per-function so that -fno-builtin* handling can be migrated to use function attributes. See discussion on D61634 for background. This is an enabler for fixing handling of these options for LTO, for example. This change should not affect behavior, as the provided function is not yet used to build a specifically per-function TLI, but rather enables that migration. Most of the changes were very mechanical, e.g. passing a Function to the legacy analysis pass's getTLI interface, or in Module level cases, adding a callback. This is similar to the way the per-function TTI analysis works. There was one place where we were looking for builtins but not in the context of a specific function. See FindCXAAtExit in lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround could provide the wrong behavior in some corner cases. Suggestions welcome. Reviewers: chandlerc, hfinkel Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66428 llvm-svn: 371284
generated by cgit v1.1 at 2025-09-30 10:01:03 +0000