aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/CallingConvLower.cpp
AgeCommit message (Collapse)AuthorFilesLines
2019-08-28[AMDGPU] Adjust number of SGPRs available in Calling ConventionRyan Taylor1-14/+4
This reduces the number of SGPRs due to some concerns about running out of SGPRs if you make all the SGPRs that aren't reserved available for the calling convention. Change-Id: Idb4ca4dc72f5b6808cb524ff7270915a8de5b4c1 llvm-svn: 370215
2019-08-05[LLVM][Alignment] Introduce Alignment In CallingConvGuillaume Chatelet1-10/+9
Summary: This is patch is part of a serie 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 Subscribers: hiraditya, llvm-commits, courbet, jfb Tags: #llvm Differential Revision: https://reviews.llvm.org/D65659 llvm-svn: 367822
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
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-02-02[CodeGen] Remove dead call-or-prologue enum from CCStateReid Kleckner1-2/+1
This enum has been dead since Olivier Stannard re-implemented ARM byval handling in r202985 (2014). llvm-svn: 293943
2016-12-21[X86] Vectorcall Calling Convention - Adding CodeGen Complete SupportOren Ben Simhon1-0/+18
The vectorcall calling convention specifies that arguments to functions are to be passed in registers, when possible. vectorcall uses more registers for arguments than fastcall or the default x64 calling convention use. The vectorcall calling convention is only supported in native code on x86 and x64 processors that include Streaming SIMD Extensions 2 (SSE2) and above. The current implementation does not handle Homogeneous Vector Aggregates (HVAs) correctly and this review attempts to fix it. This aubmit also includes additional lit tests to cover better HVAs corner cases. Differential Revision: https://reviews.llvm.org/D27392 llvm-svn: 290240
2016-03-30CodeGen: Factor out code for tail call result compatibility check; NFCMatthias Braun1-0/+36
llvm-svn: 264959
2016-01-21Avoid unnecessary stack realignment in musttail thunks with SSE2 enabledReid Kleckner1-1/+2
The X86 musttail implementation finds register parameters to forward by running the calling convention algorithm until a non-register location is returned. However, assigning a vector memory location has the side effect of increasing the function's stack alignment. We shouldn't increase the stack alignment when we are only looking for register parameters, so this change conditionalizes it. llvm-svn: 258442
2016-01-14Update to use new name alignTo().Rui Ueyama1-1/+1
llvm-svn: 257804
2015-09-29Arguments spilled on the stack before a function call may haveJeroen Ketema1-0/+3
alignment requirements, for example in the case of vectors. These requirements are exploited by the code generator by using move instructions that have similar alignment requirements, e.g., movaps on x86. Although the code generator properly aligns the arguments with respect to the displacement of the stack pointer it computes, the displacement itself may cause misalignment. For example if we have %3 = load <16 x float>, <16 x float>* %1, align 64 call void @bar(<16 x float> %3, i32 0) the x86 back-end emits: movaps 32(%ecx), %xmm2 movaps (%ecx), %xmm0 movaps 16(%ecx), %xmm1 movaps 48(%ecx), %xmm3 subl $20, %esp <-- if %esp was 16-byte aligned before this instruction, it no longer will be afterwards movaps %xmm3, (%esp) <-- movaps requires 16-byte alignment, while %esp is not aligned as such. movl $0, 16(%esp) calll __bar To solve this, we need to make sure that the computed value with which the stack pointer is changed is a multiple af the maximal alignment seen during its computation. With this change we get proper alignment: subl $32, %esp movaps %xmm3, (%esp) Differential Revision: http://reviews.llvm.org/D12337 llvm-svn: 248786
2015-06-11remove function names from comments; NFCSanjay Patel1-15/+13
llvm-svn: 239532
2015-01-12musttail: Only set the inreg flag for fastcall and vectorcallReid Kleckner1-3/+16
Otherwise we'll attempt to forward ECX, EDX, and EAX for cdecl and stdcall thunks, leaving us with no scratch registers for indirect call targets. Fixes PR22052. llvm-svn: 225729
2014-12-22Make musttail more robust for vector types on x86Reid Kleckner1-0/+56
Previously I tried to plug musttail into the existing vararg lowering code. That turned out to be a mistake, because non-vararg calls use significantly different register lowering, even on x86. For example, AVX vectors are usually passed in registers to normal functions and memory to vararg functions. Now musttail uses a completely separate lowering. Hopefully this can be used as the basis for non-x86 perfect forwarding. Reviewers: majnemer Differential Revision: http://reviews.llvm.org/D6156 llvm-svn: 224745
2014-10-14Remove unnecessary TargetMachine.h includes.Eric Christopher1-1/+0
llvm-svn: 219672
2014-08-06Remove the target machine from CCState. Previously it was only usedEric Christopher1-5/+4
to get the subtarget and that's accessible from the MachineFunction now. This helps clear the way for smaller changes where we getting a subtarget will require passing in a MachineFunction/Function as well. llvm-svn: 214988
2014-08-06Round up the size of byval arguments to MinAlignReid Kleckner1-0/+1
Otherwise we can end up with an argument frame size that is not a multiple of stack slot size, which is very awkward. This fixes PR20547, which was a bug in x86_64 Sys V vararg handling. However, it's much easier to test this with x86 callee-cleanup functions, which previously ended in "retl $6" instead of "retl $8". This does affect behavior of all backends, but it presumably fixes the same bug in all of them. llvm-svn: 214980
2014-08-04Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher1-4/+5
information and update all callers. No functional change. llvm-svn: 214781
2014-04-14[C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper1-6/+6
instead of comparing to nullptr. llvm-svn: 206142
2013-07-14Use SmallVectorImpl& instead of SmallVector to avoid repeating small vector ↵Craig Topper1-1/+1
size. llvm-svn: 186274
2013-05-05For ARM backend, fixed "byval" attribute support.Stepan Dyatkovskiy1-1/+1
Now even the small structures could be passed within byval (small enough to be stored in GPRs). In regression tests next function prototypes are checked: PR15293: %artz = type { i32 } define void @foo(%artz* byval %s) define void @foo2(%artz* byval %s, i32 %p, %artz* byval %s2) foo: "s" stored in R0 foo2: "s" stored in R0, "s2" stored in R2. Next AAPCS rules are checked: 5.5 Parameters Passing, C.4 and C.5, "ParamSize" is parameter size in 32bit words: -- NSAA != 0, NCRN < R4 and NCRN+ParamSize > R4. Parameter should be sent to the stack; NCRN := R4. -- NSAA != 0, and NCRN < R4, NCRN+ParamSize < R4. Parameter stored in GPRs; NCRN += ParamSize. llvm-svn: 181148
2013-01-02Move all of the header files which are involved in modelling the LLVM IRChandler Carruth1-1/+1
into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
2012-12-03Use the new script to sort the includes of every file under lib.Chandler Carruth1-3/+3
Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
2012-11-14Add newlines to end of debug messages.Craig Topper1-6/+6
llvm-svn: 167913
2012-10-16Issue:Stepan Dyatkovskiy1-1/+1
Stack is formed improperly for long structures passed as byval arguments for EABI mode. If we took AAPCS reference, we can found the next statements: A: "If the argument requires double-word alignment (8-byte), the NCRN (Next Core Register Number) is rounded up to the next even register number." (5.5 Parameter Passing, Stage C, C.3). B: "The alignment of an aggregate shall be the alignment of its most-aligned component." (4.3 Composite Types, 4.3.1 Aggregates). So if we have structure with doubles (9 double fields) and 3 Core unused registers (r1, r2, r3): caller should use r2 and r3 registers only. Currently r1,r2,r3 set is used, but it is invalid. Callee VA routine should also use r2 and r3 regs only. All is ok here. This behaviour is guessed by rounding up SP address with ADD+BFC operations. Fix: Main fix is in ARMTargetLowering::HandleByVal. If we detected AAPCS mode and 8 byte alignment, we waste odd registers then. P.S.: I also improved LDRB_POST_IMM regression test. Since ldrb instruction will not generated by current regression test after this patch. llvm-svn: 166018
2012-10-08Move TargetData to DataLayout.Micah Villmow1-1/+1
llvm-svn: 165402
2012-06-19Add an ensureMaxAlignment() function to MachineFrameInfo (analogous toChad Rosier1-2/+1
ensureAlignment() in MachineFunction). Also, drop setMaxAlignment() in favor of this new function. This creates a main entry point to setting MaxAlignment, which will be helpful for future work. No functionality change intended. llvm-svn: 158758
2012-06-01Switch all register list clients to the new MC*Iterator interface.Jakob Stoklund Olesen1-3/+2
No functional change intended. Sorry for the churn. The iterator classes are supposed to help avoid giant commits like this one in the future. The TableGen-produced register lists are getting quite large, and it may be necessary to change the table representation. This makes it possible to do so without changing all clients (again). llvm-svn: 157854
2012-03-04Use uint16_t to store register overlaps to reduce static data.Craig Topper1-1/+1
llvm-svn: 152001
2011-06-10Rename the ParmContext enum values to make a bit more sense and add a smallCameron Zwarich1-1/+1
comment on their meaning. llvm-svn: 132854
2011-06-10Remove tabs.Cameron Zwarich1-2/+2
llvm-svn: 132853
2011-06-10Remove a pointless const_cast.Cameron Zwarich1-1/+1
llvm-svn: 132852
2011-06-09Recommit r132764 since it didn't cause the windows buildbot failures.Eric Christopher1-0/+2
llvm-svn: 132776
2011-06-09Temporarily revert 132764 to see if it fixes the Windows buildbot.Eric Christopher1-2/+0
llvm-svn: 132771
2011-06-09If the alignment of the byval argument is greater than the alignmentEric Christopher1-0/+2
of the frame then increase the maximum alignment of the frame to match. Fixes PR6965 llvm-svn: 132764
2011-06-08Add a parameter to CCState so that it can access the MachineFunction.Eric Christopher1-6/+8
No functional change. Part of PR6965 llvm-svn: 132763
2011-05-26Reverting 132105: it broke some LLVM-GCC DejaGNU tests.Stuart Hastings1-7/+2
llvm-svn: 132108
2011-05-26Correctly handle a one-word struct passed byval on x86_64.Stuart Hastings1-2/+7
rdar://problem/6920088 llvm-svn: 132105
2011-05-17Revert 131467 due to buildbot complaint.Stuart Hastings1-6/+2
llvm-svn: 131469
2011-05-17Fix an obscure issue in X86_64 parameter passing: if a tiny byval isStuart Hastings1-2/+6
passed as the fifth parameter, insure it's passed correctly (in R9). rdar://problem/6920088 llvm-svn: 131467
2011-04-20ARM byval support. Will be enabled by another patch to the FE. ↵Stuart Hastings1-3/+4
<rdar://problem/7662569> llvm-svn: 129858
2011-03-04Improve readability with some whitespace!Eric Christopher1-1/+1
llvm-svn: 127043
2011-02-28Support for byval parameters on ARM. Will be enabled by a forthcomingStuart Hastings1-0/+2
patch to the front-end. Radar 7662569. llvm-svn: 126655
2010-12-14Simplify CCState's use of register aliases.Jakob Stoklund Olesen1-5/+3
llvm-svn: 121806
2010-11-04In the calling convention logic, ValVT is always a legal type,Duncan Sands1-1/+1
and as such can be represented by an MVT - the more complicated EVT is not needed. Use MVT for ValVT everywhere. llvm-svn: 118245
2010-11-03Inside the calling convention logic LocVT is always a simpleDuncan Sands1-15/+15
value type, so there is no point in passing it around using an EVT. Use the simpler MVT everywhere. Rather than trying to propagate this information maximally in all the code that using the calling convention stuff, I chose to do a mainly low impact change instead. llvm-svn: 118167
2010-07-10Reapply bottom-up fast-isel, with several fixes for x86-32:Dan Gohman1-5/+4
- Check getBytesToPopOnReturn(). - Eschew ST0 and ST1 for return values. - Fix the PIC base register initialization so that it doesn't ever fail to end up the top of the entry block. llvm-svn: 108039
2010-07-09--- Reverse-merging r107947 into '.':Bob Wilson1-4/+5
U utils/TableGen/FastISelEmitter.cpp --- Reverse-merging r107943 into '.': U test/CodeGen/X86/fast-isel.ll U test/CodeGen/X86/fast-isel-loads.ll U include/llvm/Target/TargetLowering.h U include/llvm/Support/PassNameParser.h U include/llvm/CodeGen/FunctionLoweringInfo.h U include/llvm/CodeGen/CallingConvLower.h U include/llvm/CodeGen/FastISel.h U include/llvm/CodeGen/SelectionDAGISel.h U lib/CodeGen/LLVMTargetMachine.cpp U lib/CodeGen/CallingConvLower.cpp U lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp U lib/CodeGen/SelectionDAG/FunctionLoweringInfo.cpp U lib/CodeGen/SelectionDAG/FastISel.cpp U lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp U lib/CodeGen/SelectionDAG/ScheduleDAGSDNodes.cpp U lib/CodeGen/SelectionDAG/InstrEmitter.cpp U lib/CodeGen/SelectionDAG/TargetLowering.cpp U lib/Target/XCore/XCoreISelLowering.cpp U lib/Target/XCore/XCoreISelLowering.h U lib/Target/X86/X86ISelLowering.cpp U lib/Target/X86/X86FastISel.cpp U lib/Target/X86/X86ISelLowering.h llvm-svn: 107987
2010-07-09Re-apply bottom-up fast-isel, with fixes. Be very careful to avoid emittingDan Gohman1-5/+4
a DBG_VALUE after a terminator, or emitting any instructions before an EH_LABEL. llvm-svn: 107943
2010-07-08Revert 107840 107839 107813 107804 107800 107797 107791.Dan Gohman1-4/+5
Debug info intrinsics win for now. llvm-svn: 107850
2010-07-07Add X86FastISel support for return statements. This entails refactoringDan Gohman1-5/+4
a bunch of stuff, to allow the target-independent calling convention logic to be employed. llvm-svn: 107800
generated by cgit v1.1 at 2025-10-08 23:20:49 +0000