aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Target/X86/X86CallFrameOptimization.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-07-12[X86] Remove unnecessary casts (NFC) (#148395)Kazu Hirata1-4/+2
getRegisterInfo() already returns const X86RegisterInfo *.
2025-03-15[X86] Use Register and MCRegister. NFCCraig Topper1-5/+5
2023-05-20[X86] Move encoding optimization for PUSH32i, PUSH64i to MC lowering, NFCIShengchen Kan1-9/+0
2023-05-20[X86][NFC] Correct the instruction names for PUSH16i, PUSH32iShengchen Kan1-1/+1
Reviewed By: maksfb Differential Revision: https://reviews.llvm.org/D151012
2023-05-19Revert "Revert "[X86] Remove patterns for ADC/SBB with immediate 8 and ↵Shengchen Kan1-12/+12
optimize during MC lowering, NFCI"" This reverts commit cb16b33a03aff70b2499c3452f2f817f3f92d20d. In fact, the test https://bugs.chromium.org/p/chromium/issues/detail?id=1446973#c2 already passed after 5586bc539acb26cb94e461438de01a5080513401
2023-05-19Revert "[X86] Remove patterns for ADC/SBB with immediate 8 and optimize ↵Hans Wennborg1-12/+12
during MC lowering, NFCI" This caused compiler assertions, see comment on https://reviews.llvm.org/D150107. This also reverts the dependent follow-up change: > [X86] Remove patterns for ADD/AND/OR/SUB/XOR/CMP with immediate 8 and optimize during MC lowering, NFCI > > This is follow-up of D150107. > > In addition, the function `X86::optimizeToFixedRegisterOrShortImmediateForm` can be > shared with project bolt and eliminates the code in X86InstrRelaxTables.cpp. > > Differential Revision: https://reviews.llvm.org/D150949 This reverts commit 2ef8ae134828876ab3ebda4a81bb2df7b095d030 and 5586bc539acb26cb94e461438de01a5080513401.
2023-05-19[X86] Remove patterns for ADD/AND/OR/SUB/XOR/CMP with immediate 8 and ↵Shengchen Kan1-12/+12
optimize during MC lowering, NFCI This is follow-up of D150107. In addition, the function `X86::optimizeToFixedRegisterOrShortImmediateForm` can be shared with project bolt and eliminates the code in X86InstrRelaxTables.cpp. Differential Revision: https://reviews.llvm.org/D150949
2021-05-15[X86] Try to pass DebugLoc by const-ref to avoid costly TrackingMDNodeRef ↵Simon Pilgrim1-1/+1
copies (REAPPLIED). NFCI. Reapply rG5ed56a821c06 (after reverted by rG7aa89c4a22fd) - don't take reference from struct that will be erased in X86FrameLowering::eliminateCallFramePseudoInstr
2021-05-14Revert "[X86] Try to pass DebugLoc by const-ref to avoid costly ↵Mitch Phillips1-1/+1
TrackingMDNodeRef copies. NFCI." This reverts commit 5ed56a821c0622869739a3ae752eea97a1ee1f48. Reason: Broke the MSan buildbots. See Phabricator for more info (https://reviews.llvm.org/rG5ed56a821c0622869739a3ae752eea97a1ee1f48).
2021-05-14[X86] Try to pass DebugLoc by const-ref to avoid costly TrackingMDNodeRef ↵Simon Pilgrim1-1/+1
copies. NFCI.
2020-11-10[NFC] Use [MC]Register for x86 targetGaurav Jain1-5/+5
Differential Revision: https://reviews.llvm.org/D91161
2020-10-31[X86] No need to determine pointer when the type is already a MachineInstr*. ↵Simon Pilgrim1-2/+1
NFCI. Caught by cppcheck - appears to be a copy+paste typo as the other var is an iterator that does need the &* pointer operation.
2020-09-09X86CallFrameOptimization.cpp - use const references where possible. NFCI.Simon Pilgrim1-5/+5
2020-05-28[x86] Propagate memory operands during call frame optimizationJean-Michel Gorius1-0/+3
Summary: Propagate memory operands when folding load instructions into instructions that directly operate on memory. The original revision has been split. See D80140 for the other part of the changes. Reviewers: craig.topper, rnk, lebedev.ri, efriedma Reviewed By: craig.topper Subscribers: lebedev.ri, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80062
2020-04-19X86InstrFMA3Info.h - remove unnecessary includes. NFC.Simon Pilgrim1-0/+1
There were a number of cpp files explicitly relying on X86InstrFMA3Info.h to include the X86.h header - so I've had to add it locally.
2020-03-29[X86] X86CallFrameOptimization - generalize slow push code pathSimon Pilgrim1-1/+1
Replace the explicit isAtom() || isSLM() test with the more general (and more specific) slowTwoMemOps() check to avoid the use of the PUSHrmm push from memory case. This is actually very tricky to test in anything but quite complex code, but the atomic-idempotent.ll tests seem to be the most straightforward to use. Differential Revision: https://reviews.llvm.org/D76239
2020-03-23[Alignment][NFC] Use TFL::getStackAlign()Guillaume Chatelet1-2/+2
Summary: 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: dylanmckay, sdardis, nemanjai, hiraditya, kbarton, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D76551
2020-02-09Support -fstack-clash-protection for x86serge_sans_paille1-3/+2
Implement protection against the stack clash attack [0] through inline stack probing. Probe stack allocation every PAGE_SIZE during frame lowering or dynamic allocation to make sure the page guard, if any, is touched when touching the stack, in a similar manner to GCC[1]. This extends the existing `probe-stack' mechanism with a special value `inline-asm'. Technically the former uses function call before stack allocation while this patch provides inlined stack probes and chunk allocation. Only implemented for x86. [0] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt [1] https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00556.html This a recommit of 39f50da2a357a8f685b3540246c5d762734e035f with proper LiveIn declaration, better option handling and more portable testing. Differential Revision: https://reviews.llvm.org/D68720
2020-02-09Revert "Support -fstack-clash-protection for x86"serge-sans-paille1-2/+3
This reverts commit 0fd51a4554f5f4f90342f40afd35b077f6d88213. Failures: http://lab.llvm.org:8011/builders/llvm-clang-win-x-armv7l/builds/4354
2020-02-09Support -fstack-clash-protection for x86serge_sans_paille1-3/+2
Implement protection against the stack clash attack [0] through inline stack probing. Probe stack allocation every PAGE_SIZE during frame lowering or dynamic allocation to make sure the page guard, if any, is touched when touching the stack, in a similar manner to GCC[1]. This extends the existing `probe-stack' mechanism with a special value `inline-asm'. Technically the former uses function call before stack allocation while this patch provides inlined stack probes and chunk allocation. Only implemented for x86. [0] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt [1] https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00556.html This a recommit of 39f50da2a357a8f685b3540246c5d762734e035f with proper LiveIn declaration, better option handling and more portable testing. Differential Revision: https://reviews.llvm.org/D68720
2020-02-08Revert "Support -fstack-clash-protection for x86"serge-sans-paille1-2/+3
This reverts commit e229017732bcf1911210903ee9811033d5588e0d. Failures: http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-debian/builds/2604 http://lab.llvm.org:8011/builders/llvm-clang-win-x-aarch64/builds/4308
2020-02-08Support -fstack-clash-protection for x86serge_sans_paille1-3/+2
Implement protection against the stack clash attack [0] through inline stack probing. Probe stack allocation every PAGE_SIZE during frame lowering or dynamic allocation to make sure the page guard, if any, is touched when touching the stack, in a similar manner to GCC[1]. This extends the existing `probe-stack' mechanism with a special value `inline-asm'. Technically the former uses function call before stack allocation while this patch provides inlined stack probes and chunk allocation. Only implemented for x86. [0] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt [1] https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00556.html This a recommit of 39f50da2a357a8f685b3540246c5d762734e035f with better option handling and more portable testing Differential Revision: https://reviews.llvm.org/D68720
2020-02-07Revert "Support -fstack-clash-protection for x86"Nico Weber1-2/+3
This reverts commit 4a1a0690ad6813a4c8cdb8dc20ea6337aa1f61e0. Breaks tests on mac and win, see https://reviews.llvm.org/D68720
2020-02-07Support -fstack-clash-protection for x86serge_sans_paille1-3/+2
Implement protection against the stack clash attack [0] through inline stack probing. Probe stack allocation every PAGE_SIZE during frame lowering or dynamic allocation to make sure the page guard, if any, is touched when touching the stack, in a similar manner to GCC[1]. This extends the existing `probe-stack' mechanism with a special value `inline-asm'. Technically the former uses function call before stack allocation while this patch provides inlined stack probes and chunk allocation. Only implemented for x86. [0] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt [1] https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00556.html This a recommit of 39f50da2a357a8f685b3540246c5d762734e035f with correct option flags set. Differential Revision: https://reviews.llvm.org/D68720
2020-02-07Revert "Support -fstack-clash-protection for x86"serge-sans-paille1-2/+3
This reverts commit 39f50da2a357a8f685b3540246c5d762734e035f. The -fstack-clash-protection is being passed to the linker too, which is not intended. Reverting and fixing that in a later commit.
2020-02-07Support -fstack-clash-protection for x86serge_sans_paille1-3/+2
Implement protection against the stack clash attack [0] through inline stack probing. Probe stack allocation every PAGE_SIZE during frame lowering or dynamic allocation to make sure the page guard, if any, is touched when touching the stack, in a similar manner to GCC[1]. This extends the existing `probe-stack' mechanism with a special value `inline-asm'. Technically the former uses function call before stack allocation while this patch provides inlined stack probes and chunk allocation. Only implemented for x86. [0] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt [1] https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00556.html Differential Revision: https://reviews.llvm.org/D68720
2019-11-06[X86] Fix uninitialized variable warnings. NFCI.Simon Pilgrim1-6/+6
2019-08-15Apply llvm-prefer-register-over-unsigned from clang-tidy to LLVMDaniel Sanders1-5/+5
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-10[X86] Fix stack probe issue on windows32.Luo, Yuanke1-0/+10
Summary: On windows if the frame size exceed 4096 bytes, compiler need to generate a call to _alloca_probe. X86CallFrameOptimization pass changes the reserved stack size and cause of stack probe function not be inserted. This patch fix the issue by detecting the call frame size, if the size exceed 4096 bytes, drop X86CallFrameOptimization. Reviewers: craig.topper, wxiao3, annita.zhang, rnk, RKSimon Reviewed By: rnk Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65923 llvm-svn: 368503
2019-08-01Finish moving TargetRegisterInfo::isVirtualRegister() and friends to ↵Daniel Sanders1-3/+3
llvm::Register as started by r367614. NFC llvm-svn: 367633
2019-06-13X86: Clean up pass initializationTom Stellard1-4/+1
Summary: - Remove redundant initializations from pass constructors that were already being initialized by LLVMInitializeX86Target(). - Add initialization function for the FPS pass. Reviewers: craig.topper Reviewed By: craig.topper Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63218 llvm-svn: 363221
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-11-01X86: Consistently declare pass initializers in X86.h; NFCMatthias Braun1-4/+0
This avoids declaring them twice: in X86TargetMachine.cpp and the file implementing the pass. llvm-svn: 345801
2018-05-09[DebugInfo] Examine all uses of isDebugValue() for debug instructions.Shiva Chen1-1/+1
Because we create a new kind of debug instruction, DBG_LABEL, we need to check all passes which use isDebugValue() to check MachineInstr is debug instruction or not. When expelling debug instructions, we should expel both DBG_VALUE and DBG_LABEL. So, I create a new function, isDebugInstr(), in MachineInstr to check whether the MachineInstr is debug instruction or not. This patch has no new test case. I have run regression test and there is no difference in regression test. Differential Revision: https://reviews.llvm.org/D45342 Patch by Hsiangkai Wang. llvm-svn: 331844
2017-12-15MachineFunction: Return reference from getFunction(); NFCMatthias Braun1-2/+2
The Function can never be nullptr so we can return a reference. llvm-svn: 320884
2017-11-17Fix a bunch more layering of CodeGen headers that are in TargetDavid Blaikie1-1/+1
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-11-08Target/TargetInstrInfo.h -> CodeGen/TargetInstrInfo.h to match layeringDavid Blaikie1-1/+1
This header includes CodeGen headers, and is not, itself, included by any Target headers, so move it into CodeGen to match the layering of its implementation. llvm-svn: 317647
2017-10-24X86CallFrameOptimization: Update comments and variable names. NFCI.Zvi Rackover1-15/+15
Following up on D38738. llvm-svn: 316434
2017-10-24X86CallFrameOptimization: Recognize 'store 0/-1 using and/or' idiomsZvi Rackover1-7/+29
Summary: r264440 added or/and patterns for storing -1 or 0 with the intention of decreasing code size. However, X86CallFrameOptimization does not recognize these memory accesses so it will not replace them with push's when profitable. This patch fixes this problem by teaching X86CallFrameOptimization these store 0/-1 idioms. An alternative fix would be to prevent the 'store 0/1 idioms' patterns from firing when accessing the stack. This would save the need to teach the pass about these idioms. However, because X86CallFrameOptimization does not always fire we may result in cases where neither X86CallFrameOptimization not the patterns for 'store 0/1 idioms' fire. Fixes pr34863 Reviewers: DavidKreitzer, guyblank, aymanmus Reviewed By: aymanmus Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D38738 llvm-svn: 316431
2017-10-24X86: Fix X86CallFrameOptimization to search for the COPY StackPointerZvi Rackover1-16/+24
SelectionDAG inserts a copy of ESP into a virtual register. X86CallFrameOptimization assumed that the COPY, if present, is always right after the call-frame setup instruction (ADJCALLSTACKDOWN). This was a wrong assumption as the COPY can be located anywhere between the call-frame setup instruction and its first use. If the COPY happened to be located in a different location than what X86CallFrameOptimization assumed, visiting it while processing the call chain would lead to a conservative bail-out. The fix is quite straightfoward, scan ahead for the stack-pointer copy and make note of it so it can be ignored while processing the call chain. Fixes pr34903 Differential Revision: https://reviews.llvm.org/D38730 llvm-svn: 316416
2017-10-24X86: Register the X86CallFrameOptimization passZvi Rackover1-4/+13
Summary: The motivation of this change is to enable .mir testing for this pass. Added one test case to cover the functionality, this same case will be improved by a future patch. Reviewers: igorb, guyblank, DavidKreitzer Reviewed By: guyblank, DavidKreitzer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D38729 llvm-svn: 316412
2017-06-29Revert "r306529 - [X86] Correct dwarf unwind information in function epilogue"Daniel Jasper1-13/+5
I am 99% sure that this breaks the PPC ASAN build bot: http://lab.llvm.org:8011/builders/sanitizer-ppc64be-linux/builds/3112/steps/64-bit%20check-asan/logs/stdio If it doesn't go back to green, we can recommit (and fix the original commit message at the same time :) ). llvm-svn: 306676
2017-06-28[X86] Correct dwarf unwind information in function epiloguePetar Jovanovic1-5/+13
CFI instructions that set appropriate cfa offset and cfa register are now inserted in emitEpilogue() in X86FrameLowering. Majority of the changes in this patch: 1. Ensure that CFI instructions do not affect code generation. 2. Enable maintaining correct information about cfa offset and cfa register in a function when basic blocks are reordered, merged, split, duplicated. These changes are target independent and described below. Changed CFI instructions so that they: 1. are duplicable 2. are not counted as instructions when tail duplicating or tail merging 3. can be compared as equal Add information to each MachineBasicBlock about cfa offset and cfa register that are valid at its entry and exit (incoming and outgoing CFI info). Add support for updating this information when basic blocks are merged, split, duplicated, created. Add a verification pass (CFIInfoVerifier) that checks that outgoing cfa offset and register of predecessor blocks match incoming values of their successors. Incoming and outgoing CFI information is used by a late pass (CFIInstrInserter) that corrects CFA calculation rule for a basic block if needed. That means that additional CFI instructions get inserted at basic block beginning to correct the rule for calculating CFA. Having CFI instructions in function epilogue can cause incorrect CFA calculation rule for some basic blocks. This can happen if, due to basic block reordering, or the existence of multiple epilogue blocks, some of the blocks have wrong cfa offset and register values set by the epilogue block above them. Patch by Violeta Vukobrat. Differential Revision: https://reviews.llvm.org/D18046 llvm-svn: 306529
2017-04-13Use methods to access data stored with frame instructionsSerge Pavlov1-6/+4
Instructions CALLSEQ_START..CALLSEQ_END and their target dependent counterparts keep data like frame size, stack adjustment etc. These data are accessed by getOperand using hard coded indices. It is error prone way. This change implements the access by special methods, which improve readability and allow changing data representation without massive changes of index values. Differential Revision: https://reviews.llvm.org/D31953 llvm-svn: 300196
2017-02-02[X86] Fix some Clang-tidy modernize and Include What You Use warnings; other ↵Eugene Zelenko1-21/+35
minor fixes (NFC). llvm-svn: 293949
2017-01-13[CodeGen] Rename MachineInstrBuilder::addOperand. NFCDiana Picus1-5/+4
Rename from addOperand to just add, to match the other method that has been added to MachineInstrBuilder for adding more than just 1 operand. See https://reviews.llvm.org/D28057 for the whole discussion. Differential Revision: https://reviews.llvm.org/D28556 llvm-svn: 291891
2016-12-07[X86] Skip over DEBUG_VALUE while looking for start of call sequenceMichael Kuperstein1-3/+3
If we don't skip over DEBUG_VALUEs, we get differences between -g and non-g code. This fixes PR31242. Differential Revision: https://reviews.llvm.org/D27485 llvm-svn: 288965
2016-12-01Move most EH from MachineModuleInfo to MachineFunctionMatthias Braun1-1/+1
Recommitting r288293 with some extra fixes for GlobalISel code. Most of the exception handling members in MachineModuleInfo is actually per function data (talks about the "current function") so it is better to keep it at the function instead of the module. This is a necessary step to have machine module passes work properly. Also: - Rename TidyLandingPads() to tidyLandingPads() - Use doxygen member groups instead of "//===- EH ---"... so it is clear where a group ends. - I had to add an ugly const_cast at two places in the AsmPrinter because the available MachineFunction pointers are const, but the code wants to call tidyLandingPads() in between (markFunctionEnd()/endFunction()). Differential Revision: https://reviews.llvm.org/D27227 llvm-svn: 288405
2016-12-01Temporarily Revert "Move most EH from MachineModuleInfo to MachineFunction"Eric Christopher1-1/+1
This apprears to have broken the global isel bot: http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-globalisel_build/5174/console This reverts commit r288293. llvm-svn: 288322
2016-11-30Move most EH from MachineModuleInfo to MachineFunctionMatthias Braun1-1/+1
Most of the exception handling members in MachineModuleInfo is actually per function data (talks about the "current function") so it is better to keep it at the function instead of the module. This is a necessary step to have machine module passes work properly. Also: - Rename TidyLandingPads() to tidyLandingPads() - Use doxygen member groups instead of "//===- EH ---"... so it is clear where a group ends. - I had to add an ugly const_cast at two places in the AsmPrinter because the available MachineFunction pointers are const, but the code wants to call tidyLandingPads() in between (markFunctionEnd()/endFunction()). Differential Revision: https://reviews.llvm.org/D27227 llvm-svn: 288293
generated by cgit v1.1 at 2025-09-29 07:24:16 +0000