aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/StackMaps.cpp
AgeCommit message (Collapse)AuthorFilesLines
2024-11-12[CodeGen] Remove unused includes (NFC) (#115996)Kazu Hirata1-1/+0
Identified with misc-include-cleaner.
2024-09-08[MC] Make MCRegisterInfo::getLLVMRegNum return std::optional<MCRegister>. ↵Craig Topper1-1/+1
NFC (#107776)
2024-01-20[Statepoint][NFC] Use uint16_t and add an assert (#78717)Danila Malyutin1-1/+1
Use a fixed width integer type and assert that DwarRegNum fits the 16 bits. This is a follow up to review comments on #78600.
2024-01-19[Statepoint] Optimize Location structure size (#78600)Danila Malyutin1-23/+17
Reduce its size from 24 to 12 bytes. Improves memory consumption when dealing with statepoint-heavy code.
2023-06-04[CodeGen] Fix incorrect usage of MCPhysReg for diff list elementsSergei Barannikov1-1/+1
The lists contain differences between register numbers, not the register numbers themselves. Since a difference can also be negative, this also changes its type to signed. Changing the type to signed exposed a "bug". For AMDGPU, which has many registers, the first element of a sequence could be as big as ~45k. The value does not fit into int16_t, but fits into uint16_t. The bug didn't show up because of unsigned wrapping and truncation of the Val field in the advance() method. To fix the issue, I changed the way regunit difflists are encoded. The 4-bit 'scale' field of MCRegisterDesc::RegUnit was replaced by 12-bit number of the first regunit, and the first element of each of the lists was removed. The higher 20 bits of RegUnit field contain the initial offset into DiffLists array. AMDGPU has 1'409 regunits (2^12 = 4'096), and the biggest offset is 80'041 (2^20 = 1'048'576). That is, there is enough room. Changing the encoding method also resulted in a smaller array size, the numbers are below (I omitted targets with less than 100 elements). ``` AMDGPU | 80052 | 78741 | -1,6% RISCV | 6498 | 6297 | -3,1% ARM | 4181 | 3966 | -5,1% AArch64 | 2770 | 2592 | -6,4% PPC | 1578 | 1441 | -8,7% Hexagon | 994 | 740 | -25,6% R600 | 508 | 398 | -21,7% VE | 471 | 459 | -2,5% Sparc | 381 | 363 | -4,7% X86 | 326 | 208 | -36,2% Mips | 253 | 200 | -20,9% SystemZ | 186 | 162 | -12,9% ``` Reviewed By: foad, arsenm Differential Revision: https://reviews.llvm.org/D151036
2023-04-18[MC] Simplify uses of subregs/superregs. NFC.Jay Foad1-3/+3
2023-04-18[MC] Use subregs/superregs instead of MCSubRegIterator/MCSuperRegIterator. NFC.Jay Foad1-2/+5
Differential Revision: https://reviews.llvm.org/D148613
2023-02-07[CodeGen] Define and use MachineOperand::getOperandNoJay Foad1-1/+1
This is a helper function to very slightly simplify many calls to MachineInstruction::getOperandNo. Differential Revision: https://reviews.llvm.org/D143250
2023-01-13[CodeGen] Remove uses of Register::isPhysicalRegister/isVirtualRegister. NFCCraig Topper1-1/+1
Use isPhysical/isVirtual methods. Reviewed By: foad Differential Revision: https://reviews.llvm.org/D141715
2023-01-09[Inline Spiller] Extend the snippet by statepoint usesSerguei Katkov1-0/+17
Snippet is a tiny live interval which has copy or fill like def and copy or spill like use at the end (any of them might abcent). Snippet has only one use/def inside interval and interval is located in one basic block. When inline spiller spills some reg around uses it also forces the spilling of connected snippets those which got by splitting the same original reg and its def is a full copy of our reg or its last use is a full copy to our reg. The definition of snippet is extended to allow not only one use/def but more. However all other uses are statepoint instructions which will fold fill into its operand. That way we do not introduce new fills/spills. Reviewed By: qcolombet, dantrushin Differential Revision: https://reviews.llvm.org/D138093
2022-11-24[Alignment][NFC] Use Align in MCStreamer::emitValueToAlignmentGuillaume Chatelet1-2/+2
Differential Revision: https://reviews.llvm.org/D138674
2022-07-17[CodeGen] Qualify auto variables in for loops (NFC)Kazu Hirata1-1/+1
2022-06-10[MC] De-capitalize SwitchSection. NFCFangrui Song1-1/+1
Add SwitchSection to return switchSection. The API will be removed soon.
2022-06-07[MC] De-capitalize MCStreamer functionsFangrui Song1-1/+1
Follow-up to c031378ce01b8485ba0ef486654bc9393c4ac024 . The class is mostly consistent now.
2021-03-30[NFC][CodeGen] Tidy up TargetRegisterInfo stack realignment functionsTomas Matheson1-1/+1
Currently needsStackRealignment returns false if canRealignStack returns false. This means that the behavior of needsStackRealignment does not correspond to it's name and description; a function might need stack realignment, but if it is not possible then this function returns false. Furthermore, needsStackRealignment is not virtual and therefore some backends have made use of canRealignStack to indicate whether a function needs stack realignment. This patch attempts to clarify the situation by separating them and introducing new names: - shouldRealignStack - true if there is any reason the stack should be realigned - canRealignStack - true if we are still able to realign the stack (e.g. we can still reserve/have reserved a frame pointer) - hasStackRealignment = shouldRealignStack && canRealignStack (not target customisable) Targets can now override shouldRealignStack to indicate that stack realignment is required. This change will make it easier in a future change to handle the case where we need to realign the stack but can't do so (for example when the register allocator creates an aligned spill after the frame pointer has been eliminated). Differential Revision: https://reviews.llvm.org/D98716 Change-Id: Ib9a4d21728bf9d08a545b4365418d3ffe1af4d87
2021-01-18[Statepoint] Handle `undef` operands in statepoint.Denis Antrushin1-0/+6
Currently when spilling statepoint register operands in FixupStatepoints we do not pay attention that it might be `undef`. We just generate a spill, which may lead to verifier error because we have a use without def. To handle it, let FixupStateponts ignore `undef` register operands completely and change them to some constant value when generating stack map. Use same value as used by ISel for this purpose (0xFEFEFEFE). Reviewed By: reames Differential Revision: https://reviews.llvm.org/D94703
2021-01-13[Verifier] Extend statepoint verifier to cover more constantsSerguei Katkov1-25/+36
Also old mir tests are updated to meet last changes in STATEPOINT format. Reviewers: reames, dantrushin Reviewed By: reames, dantrushin Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D94482
2020-12-20[Analysis, IR, CodeGen] Use llvm::erase_if (NFC)Kazu Hirata1-4/+1
2020-10-20NFC: Fix -Wsign-compare warnings on 32-bit buildsHubert Tong1-1/+1
Comparing 32-bit `ptrdiff_t` against 32-bit `unsigned` results in `-Wsign-compare` warnings for both GCC and Clang. The warning for the cases in question appear to identify an issue where the `ptrdiff_t` value would be mutated via conversion to an unsigned type. The warning is resolved by using the usual arithmetic conversions to safely preserve the value of the `unsigned` operand while trying to convert to a signed type. Host platforms where `unsigned` has the same width as `unsigned long long` will need to make a different change, but using an explicit cast has disadvantages that can be avoided for now. Reviewed By: dantrushin Differential Revision: https://reviews.llvm.org/D89612
2020-10-14Fix an apparent typo. `assert()` must not contain side-effects. NFC.Michael Liao1-1/+1
2020-10-06Silence -Wunused-variable in NDEBUG modeDmitri Gribenko1-0/+1
2020-10-06[Statepoints] Change statepoint machine instr format to better suit VReg ↵Denis Antrushin1-6/+128
lowering. Current Statepoint MI format is this: STATEPOINT <id>, <num patch bytes >, <num call arguments>, <call target>, [call arguments...], <StackMaps::ConstantOp>, <calling convention>, <StackMaps::ConstantOp>, <statepoint flags>, <StackMaps::ConstantOp>, <num deopt args>, [deopt args...], <gc base/derived pairs...> <gc allocas...> Note that GC pointers are listed in pairs <base,derived>. This causes base pointers to appear many times (at least twice) in instruction, which is bad for us when VReg lowering is ON. The problem is that machine operand tiedness is 1-1 relation, so it might look like this: %vr2 = STATEPOINT ... %vr1, %vr1(tied-def0) Since only one instance of %vr1 is tied, that may lead to incorrect codegen (see PR46917 for more details), so we have to always spill base pointers. This mostly defeats new VReg lowering scheme. This patch changes statepoint instruction format so that every gc pointer appears only once in operand list. That way they all can be tied. Additional set of operands is added to preserve base-derived relation required to build stackmap. New statepoint has following format: STATEPOINT <id>, <num patch bytes>, <num call arguments>, <call target>, [call arguments...], <StackMaps::ConstantOp>, <calling convention>, <StackMaps::ConstantOp>, <statepoint flags>, <StackMaps::ConstantOp>, <num deopt args>, [deopt args...], <StackMaps::ConstantOp>, <num gc pointers>, [gc pointers...], <StackMaps::ConstantOp>, <num gc allocas>, [gc allocas...] <StackMaps::ConstantOp>, <num entries in gc map>, [base/derived indices...] Changes are: - every gc pointer is listed only once in a flat length-prefixed list; - alloca list is prefixed with its length too; - following alloca list is length-prefixed list of base-derived indices of pointers from gc pointer list. Note that indices are logical (number of pointer), not absolute (index of machine operand). Differential Revision: https://reviews.llvm.org/D87154
2020-09-09[Statepoints] Properly handle const base pointer.Denis Antrushin1-0/+23
Current code in InstEmitter assumes all GC pointers are either VRegs or stack slots - hence, taking only one operand. But it is possible to have constant base, in which case it occupies two machine operands. Add a convinience function to StackMaps to get index of next meta argument and use it in InsrEmitter to properly advance to the next statepoint meta operand. Reviewed By: reames Differential Revision: https://reviews.llvm.org/D87252
2020-08-05[llvm-readobj/elf] - Add a testing for --stackmap and refine the implementation.Georgii Rymar1-1/+1
Currently, we only test the `--stackmap` option here: https://github.com/llvm/llvm-project/blob/master/llvm/test/Object/stackmap-dump.test it uses a precompiled MachO binary currently and I've found no tests for this option for ELF. The implementation also has issues. For example, it might assert on a wrong version of the .llvm-stackmaps section. Or it might crash on an empty or truncated section. This patch introduces a new tools/llvm-readobj/ELF test file as well as implements a few basic checks to catch simple crashes/issues It also eliminates `unwrapOrError` calls in `printStackMap()`. Differential revision: https://reviews.llvm.org/D85208
2020-02-29[MC] Add MCStreamer::emitInt{8,16,32,64}Fangrui Song1-18/+18
Similar to AsmPrinter::emitInt{8,16,32,64}.
2020-02-18[NFC] Remove trailing spaceJim Lin1-1/+1
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h,td}
2020-02-14[MCStreamer] De-capitalize EmitValue EmitIntValue{,InHex}Fangrui Song1-31/+31
2020-02-14[MC] De-capitalize another set of MCStreamer::Emit* functionsFangrui Song1-4/+4
Emit{ValueTo,Code}Alignment Emit{DTP,TP,GP}* EmitSymbolValue etc
2019-12-19[StackMaps] Be explicit about label formation [NFC] (try 2)Philip Reames1-11/+11
Recommit after making the same API change in non-x86 targets. This has been build for all targets, and tested for effected ones. Why the difference? Because my disk filled up when I tried make check for all. For auto-padding assembler support, we'll need to bundle the label with the instructions (nops or call sequences) so that they don't get separated. This just rearranges the code to make the upcoming change more obvious.
2019-12-19Temporarily Revert "[StackMaps] Be explicit about label formation [NFC]"Eric Christopher1-11/+11
as it broke the aarch64 build. This reverts commit bc7595d934b958ab481288d7b8e768fe5310be8f.
2019-12-19[StackMaps] Be explicit about label formation [NFC]Philip Reames1-11/+11
For auto-padding assembler support, we'll need to bundle the label with the instructions (nops or call sequences) so that they don't get separated. This just rearranges the code to make the upcoming change more obvious.
2019-11-09Fix operator precedence warning. NFC.Simon Pilgrim1-1/+1
2019-09-24MCRegisterInfo: Merge getLLVMRegNum and getLLVMRegNumFromEHPavel Labath1-1/+1
Summary: The functions different in two ways: - getLLVMRegNum could return both "eh" and "other" dwarf register numbers, while getLLVMRegNumFromEH only returned the "eh" number. - getLLVMRegNum asserted if the register was not found, while the second function returned -1. The second distinction was pretty important, but it was very hard to infer that from the function name. Aditionally, for the use case of dumping dwarf expressions, we needed a function which can work with both kinds of number, but does not assert. This patch solves both of these issues by merging the two functions into one, returning an Optional<unsigned> value. While the same thing could be achieved by adding an "IsEH" argument to the (renamed) getLLVMRegNumFromEH function, it seemed better to avoid the confusion of two functions and put the choice of asserting into the hands of the caller -- if he checks the Optional value, he can safely process "untrusted" input, and if he blindly dereferences the Optional, he gets the assertion. I've updated all call sites to the new API, choosing between the two options according to the function they were calling originally, except that I've updated the usage in DWARFExpression.cpp to use the "safe" method instead, and added a test case which would have previously triggered an assertion failure when processing (incorrect?) dwarf expressions. Reviewers: dsanders, arsenm, JDevlieghere Subscribers: wdng, aprantl, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67154 llvm-svn: 372710
2019-08-15Apply llvm-prefer-register-over-unsigned from clang-tidy to LLVMDaniel Sanders1-2/+2
Summary: This clang-tidy check is looking for unsigned integer variables whose initializer starts with an implicit cast from llvm::Register and changes the type of the variable to llvm::Register (dropping the llvm:: where possible). Partial reverts in: X86FrameLowering.cpp - Some functions return unsigned and arguably should be MCRegister X86FixupLEAs.cpp - Some functions return unsigned and arguably should be MCRegister X86FrameLowering.cpp - Some functions return unsigned and arguably should be MCRegister HexagonBitSimplify.cpp - Function takes BitTracker::RegisterRef which appears to be unsigned& MachineVerifier.cpp - Ambiguous operator==() given MCRegister and const Register PPCFastISel.cpp - No Register::operator-=() PeepholeOptimizer.cpp - TargetInstrInfo::optimizeLoadInstr() takes an unsigned& MachineTraceMetrics.cpp - MachineTraceMetrics lacks a suitable constructor Manual fixups in: ARMFastISel.cpp - ARMEmitLoad() now takes a Register& instead of unsigned& HexagonSplitDouble.cpp - Ternary operator was ambiguous between unsigned/Register HexagonConstExtenders.cpp - Has a local class named Register, used llvm::Register instead of Register. PPCFastISel.cpp - PPCEmitLoad() now takes a Register& instead of unsigned& Depends on D65919 Reviewers: arsenm, bogner, craig.topper, RKSimon Reviewed By: arsenm Subscribers: RKSimon, craig.topper, lenary, aemerson, wuzish, jholewinski, MatzeB, qcolombet, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, wdng, nhaehnle, sbc100, jgravelle-google, kristof.beyls, hiraditya, aheejin, kbarton, fedor.sergeev, javed.absar, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, tpr, PkmX, jocewei, jsji, Petar.Avramovic, asbirlea, Jim, s.egerton, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65962 llvm-svn: 369041
2019-08-01Finish moving TargetRegisterInfo::isVirtualRegister() and friends to ↵Daniel Sanders1-1/+1
llvm::Register as started by r367614. NFC llvm-svn: 367633
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2018-09-27llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song1-5/+4
Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D52573 llvm-svn: 343163
2018-05-14Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen1-11/+11
The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it. In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one. Differential Revision: https://reviews.llvm.org/D43624 llvm-svn: 332240
2018-04-06[CodeGen] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang1-5/+5
Summary: r327219 added wrappers to std::sort which randomly shuffle the container before sorting. This will help in uncovering non-determinism caused due to undefined sorting order of objects having the same key. To make use of that infrastructure we need to invoke llvm::sort instead of std::sort. Note: This patch is one of a series of patches to replace *all* std::sort to llvm::sort. Refer the comments section in D44363 for a list of all the required patches. Reviewers: bogner, rnk, MatzeB, RKSimon Reviewed By: rnk Subscribers: JDevlieghere, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D45133 llvm-svn: 329435
2017-12-01Mark all library options as hidden.Zachary Turner1-1/+1
These command line options are not intended for public use, and often don't even make sense in the context of a particular tool anyway. About 90% of them are already hidden, but when people add new options they forget to hide them, so if you were to make a brand new tool today, link against one of LLVM's libraries, and run tool -help you would get a bunch of junk that doesn't make sense for the tool you're writing. This patch hides these options. The real solution is to not have libraries defining command line options, but that's a much larger effort and not something I'm prepared to take on. Differential Revision: https://reviews.llvm.org/D40674 llvm-svn: 319505
2017-11-30[CodeGen] Always use `printReg` to print registers in both MIR and debugFrancis Visoiu Mistrih1-4/+4
output As part of the unification of the debug format and the MIR format, always use `printReg` to print all kinds of registers. Updated the tests using '_' instead of '%noreg' until we decide which one we want to be the default one. Differential Revision: https://reviews.llvm.org/D40421 llvm-svn: 319445
2017-11-17Fix a bunch more layering of CodeGen headers that are in TargetDavid Blaikie1-3/+3
All these headers already depend on CodeGen headers so moving them into CodeGen fixes the layering (since CodeGen depends on Target, not the other way around). llvm-svn: 318490
2017-06-06Sort the remaining #include lines in include/... and lib/....Chandler Carruth1-1/+1
I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
2017-04-28[StackMaps] Increase the size of the "location size" fieldSanjoy Das1-6/+12
Summary: In some cases LLVM (especially the SLP vectorizer) will create vectors that are 256 bytes (or larger). Given that this is intentional[0] is likely to get more common, this patch updates the StackMap binary format to deal with the spill locations for said vectors. This change also bumps the stack map version from 2 to 3. [0]: https://reviews.llvm.org/D32533#738350 Reviewers: reames, kavon, skatkov, javed.absar Subscribers: mcrosier, nemanjai, llvm-commits Differential Revision: https://reviews.llvm.org/D32629 llvm-svn: 301615
2017-04-24Move size and alignment information of regclass to TargetRegisterInfoKrzysztof Parzyszek1-2/+3
1. RegisterClass::getSize() is split into two functions: - TargetRegisterInfo::getRegSizeInBits(const TargetRegisterClass &RC) const; - TargetRegisterInfo::getSpillSize(const TargetRegisterClass &RC) const; 2. RegisterClass::getAlignment() is replaced by: - TargetRegisterInfo::getSpillAlignment(const TargetRegisterClass &RC) const; This will allow making those values depend on subtarget features in the future. Differential Revision: https://reviews.llvm.org/D31783 llvm-svn: 301221
2017-02-22[CodeGen] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko1-6/+18
other minor fixes (NFC). llvm-svn: 295893
2016-09-14[Stackmap] Added callsite counts to emitted function information.Sanjoy Das1-13/+21
Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-08-23[stackmaps] Remove an unneeded member variable [NFC]Philip Reames1-2/+1
llvm-svn: 279590
2016-08-23[stackmaps] More extraction of common code [NFCI]Philip Reames1-6/+5
General cleanup before starting to work on the part I want to actually change. llvm-svn: 279586
2016-08-23Remove unused data member to unbreak -Werror builds.Richard Smith1-2/+1
llvm-svn: 279581
generated by cgit v1.1 at 2025-09-30 15:39:27 +0000