summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/SelectionDAG/FunctionLoweringInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Simplify FunctionLoweringInfo.cpp with range for loopsReid Kleckner2016-12-301-40/+31
| | | | | | | I'm preparing to add some pattern matching code here, so simplify the code before I do. NFC llvm-svn: 290731
* Move most EH from MachineModuleInfo to MachineFunctionMatthias Braun2016-12-011-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
* Temporarily Revert "Move most EH from MachineModuleInfo to MachineFunction"Eric Christopher2016-12-011-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
* Move most EH from MachineModuleInfo to MachineFunctionMatthias Braun2016-11-301-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
* Move VariableDbgInfo from MachineModuleInfo to MachineFunctionMatthias Braun2016-11-301-1/+1
| | | | | | | | | | | VariableDbgInfo is per function data, so it makes sense to have it with the function instead of the module. This is a necessary step to have machine module passes work properly. Differential Revision: https://reviews.llvm.org/D27186 llvm-svn: 288292
* [CodeGen] Pull MMI helpers from FunctionLoweringInfo to MMI. NFC.Ahmed Bougacha2016-11-161-56/+0
| | | | | | | | | | | They're not SelectionDAG- or FunctionLoweringInfo-specific. They are, however, specific to building MMI from IR. We could make them members, but it's nice having MMI be a "simple" data structure and this logic kept separate. This also lets us reuse them from GlobalISel. llvm-svn: 287167
* [WinEH] Allow catchpads to reuse the same catch objectReid Kleckner2016-10-191-4/+7
| | | | | | This code used a regular when it should have used a multimap. llvm-svn: 284612
* swifterror: Don't compute swifterror vregs during instruction selectionArnold Schwaighofer2016-10-071-12/+20
| | | | | | | | | | | | | | | | | | | | | | | | | The code used llvm basic block predecessors to decided where to insert phi nodes. Instruction selection can and will liberally insert new machine basic block predecessors. There is not a guaranteed one-to-one mapping from pred. llvm basic blocks and machine basic blocks. Therefore the current approach does not work as it assumes we can mark predecessor machine basic block as needing a copy, and needs to know the set of all predecessor machine basic blocks to decide when to insert phis. Instead of computing the swifterror vregs as we select instructions, propagate them at the end of instruction selection when the MBB CFG is complete. When an instruction needs a swifterror vreg and we don't know the value yet, generate a new vreg and remember this "upward exposed" use, and reconcile this at the end of instruction selection. This will only happen if the target supports promoting swifterror parameters to registers and the swifterror attribute is used. rdar://28300923 llvm-svn: 283617
* Use the range variant of find instead of unpacking begin/endDavid Majnemer2016-08-111-4/+2
| | | | | | | | | If the result of the find is only used to compare against end(), just use is_contained instead. No functionality change is intended. llvm-svn: 278433
* MachineFunction: Return reference for getFrameInfo(); NFCMatthias Braun2016-07-281-8/+8
| | | | | | | getFrameInfo() never returns nullptr so we should use a reference instead of a pointer. llvm-svn: 277017
* Swift Calling Convention: swifterror target-independent change.Manman Ren2016-04-051-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At IR level, the swifterror argument is an input argument with type ErrorObject**. For targets that support swifterror, we want to optimize it to behave as an inout value with type ErrorObject*; it will be passed in a fixed physical register. The main idea is to track the virtual registers for each swifterror value. We define swifterror values as AllocaInsts with swifterror attribute or a function argument with swifterror attribute. In SelectionDAGISel.cpp, we set up swifterror values (SwiftErrorVals) before handling the basic blocks. When iterating over all basic blocks in RPO, before actually visiting the basic block, we call mergeIncomingSwiftErrors to merge incoming swifterror values when there are multiple predecessors or to simply propagate them. There, we create a virtual register for each swifterror value in the entry block. For predecessors that are not yet visited, we create virtual registers to hold the swifterror values at the end of the predecessor. The assignments are saved in SwiftErrorWorklist and will be materialized at the end of visiting the basic block. When visiting a load from a swifterror value, we copy from the current virtual register assignment. When visiting a store to a swifterror value, we create a virtual register to hold the swifterror value and update SwiftErrorMap to track the current virtual register assignment. Differential Revision: http://reviews.llvm.org/D18108 llvm-svn: 265433
* [Statepoints] Fix yet another issue around gc pointer uniqueingSanjoy Das2016-03-241-1/+1
| | | | | | | | | | | | | Given that StatepointLowering now uniques derived pointers before putting them in the per-statepoint spill map, we may end up with missing entries for derived pointers when we visit a gc.relocate on a pointer that was de-duplicated away. Fix this by keeping two maps, one mapping gc pointers to their de-duplicated values, and one mapping a de-duplicated value to the slot it is spilled in. llvm-svn: 264320
* [X86] Don't give catch objects a displacement of zeroDavid Majnemer2016-03-031-20/+40
| | | | | | | | | | | | | | | | | | Catch objects with a displacement of zero do not initialize a catch object. The displacement is relative to %rsp at the end of the function's prologue for x86_64 targets. If we place an object at the top-of-stack, we will end up wit a displacement of zero resulting in our catch object remaining uninitialized. Address this by creating our catch objects as fixed objects. We will ensure that the UnwindHelp object is created after the catch objects so that no catch object will have a displacement of zero. Differential Revision: http://reviews.llvm.org/D17823 llvm-svn: 262546
* Undo spurious change made in r256965David Majnemer2016-01-071-2/+1
| | | | llvm-svn: 257028
* [WinEH] Remove calculateCatchReturnSuccessorColorsDavid Majnemer2016-01-061-3/+2
| | | | | | | | | | | | | | The functionality that calculateCatchReturnSuccessorColors provides was once non-trivial: it was a computation layered on top of funclet coloring. These days, LLVM IR directly encodes what calculateCatchReturnSuccessorColors computed, obsoleting the need for it. No functionality change is intended. llvm-svn: 256965
* Fix funciton->function typo.Eric Christopher2015-12-161-1/+1
| | | | llvm-svn: 255841
* [IR] Reformulate LLVM's EH funclet IRDavid Majnemer2015-12-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
* [Stack realignment] Handling of aligned allocas.Jonas Paulsson2015-11-281-13/+15
| | | | | | | | | | | | | | | | | | | | This patch implements dynamic realignment of stack objects for targets with a non-realigned stack pointer. Behaviour in FunctionLoweringInfo is changed so that for a target that has StackRealignable set to false, over-aligned static allocas are considered to be variable-sized objects and are handled with DYNAMIC_STACKALLOC nodes. It would be good to group aligned allocas into a single big alloca as an optimization, but this is yet todo. SystemZ benefits from this, due to its stack frame layout. New tests SystemZ/alloca-03.ll for aligned allocas, and SystemZ/alloca-04.ll for "no-realign-stack" attribute on functions. Review and help from Ulrich Weigand and Hal Finkel. llvm-svn: 254227
* [WinEH] Move WinEHFuncInfo from MachineModuleInfo to MachineFunctionReid Kleckner2015-11-171-19/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Now that there is a one-to-one mapping from MachineFunction to WinEHFuncInfo, we don't need to use a DenseMap to select the right WinEHFuncInfo for the current funclet. The main challenge here is that X86WinEHStatePass is an IR pass that doesn't have access to the MachineFunction. I gave it its own WinEHFuncInfo object that it uses to calculate state numbers, which it then throws away. As long as nobody creates or removes EH pads between this pass and SDAG construction, we will get the same state numbers. The other thing X86WinEHStatePass does is to mark the EH registration node. Instead of communicating which alloca was the registration through WinEHFuncInfo, I added the llvm.x86.seh.ehregnode intrinsic. This intrinsic generates no code and simply marks the alloca in use. Reviewers: JCTremoulet Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14668 llvm-svn: 253378
* [WinEH] Fix funclet prologues with stack realignmentReid Kleckner2015-11-051-2/+6
| | | | | | | | | | | | | | We already had a test for this for 32-bit SEH catchpads, but those don't actually create funclets. We had a bug that only appeared in funclet prologues, where we would establish EBP and ESI as our FP and BP, and then downstream prologue code would overwrite them. While I was at it, I fixed Win64+funclets+stackrealign. This issue doesn't come up as often there due to the ABI requring 16 byte stack alignment, but now we can rest easy that AVX and WinEH will work well together =P. llvm-svn: 252210
* [CodeGen] Remove usage of NDEBUG in header.Davide Italiano2015-10-231-7/+0
| | | | | | Moreover, this seems unused. llvm-svn: 251081
* SelectionDAG: Remove implicit ilist iterator conversions, NFCDuncan P. N. Exon Smith2015-10-131-10/+9
| | | | llvm-svn: 250214
* [WinEH] Remove CatchObjRecoverIdxDavid Majnemer2015-10-121-1/+1
| | | | | | | CatchObjRecoverIdx was used for the old scheme, it is no longer relevant. llvm-svn: 250065
* [WinEH] Remove more dead codeDavid Majnemer2015-10-101-9/+7
| | | | | | wineh-parent is dead, so is ValueOrMBB. llvm-svn: 249920
* [WinEH] Delete the old landingpad implementation of Windows EHReid Kleckner2015-10-091-44/+1
| | | | | | | | | | | The new implementation works at least as well as the old implementation did. Also delete the associated preparation tests. They don't exercise interesting corner cases of the new implementation. All the codegen tests of the EH tables have already been ported. llvm-svn: 249918
* [SEH] Add llvm.eh.exceptioncode intrinsicReid Kleckner2015-10-071-0/+11
| | | | | | This will support the Clang __exception_code intrinsic. llvm-svn: 249492
* [WinEH] Create a separate MBB for funclet prologuesDavid Majnemer2015-10-061-2/+5
| | | | | | | | | | | | | | | | Our current emission strategy is to emit the funclet prologue in the CatchPad's normal destination. This is problematic because intra-funclet control flow to the normal destination is not erroneous and results in us reevaluating the prologue if said control flow is taken. Instead, use the CatchPad's location for the funclet prologue. This correctly models our desire to have unwind edges evaluate the prologue but edges to the normal destination result in typical control flow. Differential Revision: http://reviews.llvm.org/D13424 llvm-svn: 249483
* [WinEH] Implement state numbering for CoreCLRJoseph Tremoulet2015-10-061-0/+6
| | | | | | | | | | | | | | | | Summary: Assign one state number per handler/funclet, tracking parent state, handler type, and catch type token. State numbers are arranged such that ancestors have lower state numbers than their descendants. Reviewers: majnemer, andrew.w.kaylor, rnk Subscribers: pgavlin, AndyAyers, llvm-commits Differential Revision: http://reviews.llvm.org/D13450 llvm-svn: 249457
* [WinEH] Recognize CoreCLR personality functionJoseph Tremoulet2015-10-061-2/+2
| | | | | | | | | | | | | | | Summary: - Add CoreCLR to if/else ladders and switches as appropriate. - Rename isMSVCEHPersonality to isFuncletEHPersonality to better reflect what it captures. Reviewers: majnemer, andrew.w.kaylor, rnk Subscribers: pgavlin, AndyAyers, llvm-commits Differential Revision: http://reviews.llvm.org/D13449 llvm-svn: 249455
* [WinEH] Make FuncletLayout more robust against catchretDavid Majnemer2015-10-011-1/+3
| | | | | | | | | Catchret transfers control from a catch funclet to an earlier funclet. However, it is not completely clear which funclet the catchret target is part of. Make this clear by stapling the catchret target's funclet membership onto the CATCHRET SDAG node. llvm-svn: 249052
* [WinEH] Pull Adjectives and CatchObj out of the catchpad arg listReid Kleckner2015-09-161-4/+11
| | | | | | | | | | Clang now passes the adjectives as an argument to catchpad. Getting the CatchObj working is simply a matter of threading another static alloca through codegen, first as an alloca, then as a frame index, and finally as a frame offset. llvm-svn: 247844
* [WinEH] Add codegen support for cleanuppad and cleanupretReid Kleckner2015-09-101-17/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | All of the complexity is in cleanupret, and it mostly follows the same codepaths as catchret, except it doesn't take a return value in RAX. This small example now compiles and executes successfully on win32: extern "C" int printf(const char *, ...) noexcept; struct Dtor { ~Dtor() { printf("~Dtor\n"); } }; void has_cleanup() { Dtor o; throw 42; } int main() { try { has_cleanup(); } catch (int) { printf("caught it\n"); } } Don't try to put the cleanup in the same function as the catch, or Bad Things will happen. llvm-svn: 247219
* [SEH] Emit 32-bit SEH tables for the new EH IRReid Kleckner2015-09-091-8/+18
| | | | | | | | | | | The 32-bit tables don't actually contain PC range data, so emitting them is incredibly simple. The 64-bit tables, on the other hand, use the same table for state numbering as well as label ranges. This makes things more difficult, so it will be implemented later. llvm-svn: 247192
* [WinEH] Avoid creating MBBs for LLVM BBs that cannot contain codeReid Kleckner2015-09-081-2/+18
| | | | | | | | | | | | | | Typically these are catchpads, which hold data used to decide whether to catch the exception or continue unwinding. We also shouldn't create MBBs for catchendpads, cleanupendpads, or terminatepads, since no real code can live in them. This fixes a problem where MI passes (like the register allocator) would try to put code into catchpad blocks, which are not executed by the runtime. In the new world, blocks ending in invokes now have many possible successors. llvm-svn: 247102
* [WinEH] Emit prologues and epilogues for funcletsReid Kleckner2015-09-081-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | Summary: 32-bit funclets have short prologues that allocate enough stack for the largest call in the whole function. The runtime saves CSRs for the funclet. It doesn't restore CSRs after we finally transfer control back to the parent funciton via a CATCHRET, but that's a separate issue. 32-bit funclets also have to adjust the incoming EBP value, which is what llvm.x86.seh.recoverframe does in the old model. 64-bit funclets need to spill CSRs as normal. For simplicity, this just spills the same set of CSRs as the parent function, rather than trying to compute different CSR sets for the parent function and each funclet. 64-bit funclets also allocate enough stack space for the largest outgoing call frame, like 32-bit. Reviewers: majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12546 llvm-svn: 247092
* [EH] Handle non-Function personalities like unknown personalitiesReid Kleckner2015-08-311-4/+3
| | | | | | | | | Also delete and simplify a lot of MachineModuleInfo code that used to be needed to handle personalities on landingpads. Now that the personality is on the LLVM Function, we no longer need to track it this way on MMI. Certainly it should not live on LandingPadInfo. llvm-svn: 246478
* [WinEH] Add some support for code generating catchpadReid Kleckner2015-08-271-7/+13
| | | | | | | We can now run 32-bit programs with empty catch bodies. The next step is to change PEI so that we get funclet prologues and epilogues. llvm-svn: 246235
* [WinEH] Calculate state numbers for the new EH representationDavid Majnemer2015-08-181-1/+1
| | | | | | | | | | | State numbers are calculated by performing a walk from the innermost funclet to the outermost funclet. Rudimentary support for the new EH constructs has been added to the assembly printer, just enough to test the new machinery. Differential Revision: http://reviews.llvm.org/D12098 llvm-svn: 245331
* Redirect DataLayout from TargetMachine to Module in ComputeValueVTs()Mehdi Amini2015-07-091-4/+5
| | | | | | | | | | | | | | | | | | | | Summary: Avoid using the TargetMachine owned DataLayout and use the Module owned one instead. This requires passing the DataLayout up the stack to ComputeValueVTs(). This change is part of a series of commits dedicated to have a single DataLayout during compilation by using always the one owned by the module. Reviewers: echristo Subscribers: jholewinski, yaron.keren, rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D11019 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 241773
* [WinEH] Make llvm.x86.seh.restoreframe work for stack realignment prologuesReid Kleckner2015-07-071-1/+1
| | | | | | | | | | The incoming EBP value points to the end of a local stack allocation, so we can use that to restore ESI, the base pointer. Once we do that, we can use local stack allocations. If we know we need stack realignment, spill the original frame pointer in the prologue and reload it after restoring ESI. llvm-svn: 241648
* Redirect DataLayout from TargetMachine to Module in SelectionDAGMehdi Amini2015-07-071-7/+7
| | | | | | | | | | | | | | | | | | | | Summary: SelectionDAG itself is not invoking directly the DataLayout in the TargetMachine, but the "TargetLowering" class is still using it. I'll address it in a following commit. This change is part of a series of commits dedicated to have a single DataLayout during compilation by using always the one owned by the module. Reviewers: echristo Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11000 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 241618
* Move the personality function from LandingPadInst to FunctionDavid Majnemer2015-06-171-4/+6
| | | | | | | | | | | | | | | | | | | The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
* [WinEH] Add 32-bit SEH state table emission prototypeReid Kleckner2015-06-091-5/+12
| | | | | | | | | | | | This gets all the handler info through to the asm printer and we can look at the .xdata tables now. I've convinced one small catch-all test case to work, but other than that, it would be a stretch to say this is functional. The state numbering algorithm avoids doing any scope reconstruction as we do for C++ to simplify the implementation. llvm-svn: 239433
* [WinEH] Start inserting state number stores for C++ EHReid Kleckner2015-05-281-371/+3
| | | | | | | | | | | | This moves all the state numbering code for C++ EH to WinEHPrepare so that we can call it from the X86 state numbering IR pass that runs before isel. Now we just call the same state numbering machinery and insert a bunch of stores. It also populates MachineModuleInfo with information about the current function. llvm-svn: 238514
* Fix build warningAndrew Kaylor2015-05-201-1/+1
| | | | llvm-svn: 237855
* [WinEH] C++ EH state numbering fixesAndrew Kaylor2015-05-201-52/+179
| | | | | | Differential Revision: http://reviews.llvm.org/D9787 llvm-svn: 237854
* [StatepointLowering] Support of the gc.relocates for invoke statepoints.Igor Laevsky2015-05-201-0/+1
| | | | | | | | | | This change implements support for lowering of the gc.relocates tied to the invoke statepoint. This is acomplished by storing frame indices of the lowered values in "StatepointRelocatedValues" map inside FunctionLoweringInfo instead of storing them in per-basic block structure StatepointLowering. After this change StatepointLowering is used only during "LowerStatepoint" call and it is not necessary to store it as a field in SelectionDAGBuilder anymore. Differential Revision: http://reviews.llvm.org/D7798 llvm-svn: 237786
* [WinEH] Push unique_ptr through the Action interface.Benjamin Kramer2015-05-161-21/+15
| | | | | | | This was the source of many leaks in the past, this should fix them once and for all. llvm-svn: 237524
* Fixing build warningsAndrew Kaylor2015-05-111-2/+2
| | | | llvm-svn: 237042
* [WinEH] Update exception numbering to give handlers their own base state.Andrew Kaylor2015-05-111-15/+74
| | | | | | Differential Revision: http://reviews.llvm.org/D9512 llvm-svn: 237014
OpenPOWER on IntegriCloud