summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [WinEH] Sink UnwindHelp completely out of IRDavid Majnemer2015-04-031-11/+0
| | | | | | | | We don't need to represent UnwindHelp in IR. Instead, we can use the knowledge that we are emitting the parent function to decide if we should create the UnwindHelp stack object. llvm-svn: 234061
* CodeGen: Assert that inlined-at locations agreeDuncan P. N. Exon Smith2015-04-031-8/+13
| | | | | | | | | | | | | | | | | As a follow-up to r234021, assert that a debug info intrinsic variable's `MDLocalVariable::getInlinedAt()` always matches the `MDLocation::getInlinedAt()` of its `!dbg` attachment. The goal here is to get rid of `MDLocalVariable::getInlinedAt()` entirely (PR22778), but I'll let these assertions bake for a while first. If you have an out-of-tree backend that just broke, you're probably attaching the wrong `DebugLoc` to a `DBG_VALUE` instruction. The one you want is the location that was attached to the corresponding `@llvm.dbg.declare` or `@llvm.dbg.value` call that you started with. llvm-svn: 234038
* SelectionDAG: Use specialized metadata nodes in EmitFuncArgumentDbgValue(), NFCDuncan P. N. Exon Smith2015-04-031-11/+9
| | | | | | | Use `MDLocalVariable` and `MDExpression` directly for the arguments of `EmitFuncArgumentDbgValue()` to simplify a follow-up patch. llvm-svn: 234026
* [WinEH] Generate .xdata for catch handlersDavid Majnemer2015-03-311-12/+0
| | | | | | | | | | | | | | This lets us catch exceptions in simple cases. N.B. Things that do not work include (but are not limited to): - Throwing from within a catch handler. - Catching an object with a named catch parameter. - 'CatchHigh' is fictitious, we aren't sure of its purpose. - We aren't entirely efficient with regards to the number of EH states that we generate. - IP-to-State tables are sensitive to the order of emission. llvm-svn: 233767
* [WinEH] Run cleanup handlers when an exception is thrownDavid Majnemer2015-03-301-4/+11
| | | | | | | | Generate tables in the .xdata section representing what actions to take when an exception is thrown. This currently fills in state for cleanups, catch handlers are still unfinished. llvm-svn: 233636
* [CodeGen] Don't attempt a tail-call with a non-forwarded explicit sret.Ahmed Bougacha2015-03-271-0/+5
| | | | | | | | | | | | Tailcalls are only OK with forwarded sret pointers. With explicit sret, one approximation is to check that the pointer isn't an Instruction, as in that case it might point into some local memory (alloca). That's not OK with tailcalls. Explicit sret counterpart to r233409. Differential Revison: http://reviews.llvm.org/D8510 llvm-svn: 233410
* [CodeGen] Don't attempt a tail-call with implicit sret.Ahmed Bougacha2015-03-271-0/+4
| | | | | | | | | Tailcalls are only OK with forwarded sret pointers. With sret demotion, they're not, as we'd have a pointer into a soon-to-be-dead stack frame. Differential Revison: http://reviews.llvm.org/D8510 llvm-svn: 233409
* WinEH: Create a parent frame alloca for HandlerType xdata tablesDavid Majnemer2015-03-271-1/+11
| | | | | | | | We don't have any logic to emit those tables yet, so the SDAG lowering of this intrinsic is just a stub. We can see the intrinsic in the prepared IR, though. llvm-svn: 233354
* WinEH: Create an unwind help alloca for __CxxFrameHandler3 xdata tablesReid Kleckner2015-03-251-0/+10
| | | | | | | | We don't have any logic to emit those tables yet, so the sdag lowering of this intrinsic is just a stub. We can see the intrinsic in the prepared IR, though. llvm-svn: 233209
* SelectionDAGBuilder: Rangeify a loop. NFC.Hans Wennborg2015-03-201-8/+6
| | | | llvm-svn: 232831
* SelectionDAGBuilder::handleJTSwitchCase, simplify loop; NFCHans Wennborg2015-03-201-9/+4
| | | | llvm-svn: 232830
* Rewrite SelectionDAGBuilder::Clusterify to run in linear time. NFC.Hans Wennborg2015-03-201-37/+34
| | | | | | | It was previously repeatedly erasing elements from the middle of a vector, causing O(n^2) worst-case run-time. llvm-svn: 232789
* Switch lowering: extract NextBlock function. NFC.Hans Wennborg2015-03-191-54/+21
| | | | llvm-svn: 232759
* Switch lowering: remove unnecessary ConstantInt casts. NFC.Hans Wennborg2015-03-191-22/+20
| | | | llvm-svn: 232729
* SelectionDAGBuilder: update comment in HandlePHINodesInSuccessorBlocks.Hans Wennborg2015-03-191-2/+2
| | | | | | | From what I can tell, the code is checking for PHIs that expect any value from this block, not just constants. llvm-svn: 232697
* Recommit r232027 with PR22883 fixed: Add infrastructure for support of ↵Daniel Sanders2015-03-131-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | multiple memory constraints. The operand flag word for ISD::INLINEASM nodes now contains a 15-bit memory constraint ID when the operand kind is Kind_Mem. This constraint ID is a numeric equivalent to the constraint code string and is converted with a target specific hook in TargetLowering. This patch maps all memory constraints to InlineAsm::Constraint_m so there is no functional change at this point. It just proves that using these previously unused bits in the encoding of the flag word doesn't break anything. The next patch will make each target preserve the current mapping of everything to Constraint_m for itself while changing the target independent implementation of the hook to return Constraint_Unknown appropriately. Each target will then be adapted in separate patches to use appropriate Constraint_* values. PR22883 was caused the matching operands copying the whole of the operand flags for the matched operand. This included the constraint id which needed to be replaced with the operand number. This has been fixed with a conversion function. Following on from this, matching operands also used the operand number as the constraint id. This has been fixed by looking up the matched operand and taking it from there. llvm-svn: 232165
* [X86, AVX2] Replace inserti128 and extracti128 intrinsics with generic shufflesSanjay Patel2015-03-121-22/+0
| | | | | | | | | | | | | | | | | This should complete the job started in r231794 and continued in r232045: We want to replace as much custom x86 shuffling via intrinsics as possible because pushing the code down the generic shuffle optimization path allows for better codegen and less complexity in LLVM. AVX2 introduced proper integer variants of the hacked integer insert/extract C intrinsics that were created for this same functionality with AVX1. This should complete the removal of insert/extract128 intrinsics. The Clang precursor patch for this change was checked in at r232109. llvm-svn: 232120
* Revert "r232027 - Add infrastructure for support of multiple memory constraints"Hal Finkel2015-03-121-12/+0
| | | | | | | | | | | | | | | | | | | | | | | | This (r232027) has caused PR22883; so it seems those bits might be used by something else after all. Reverting until we can figure out what else to do. Original commit message: The operand flag word for ISD::INLINEASM nodes now contains a 15-bit memory constraint ID when the operand kind is Kind_Mem. This constraint ID is a numeric equivalent to the constraint code string and is converted with a target specific hook in TargetLowering. This patch maps all memory constraints to InlineAsm::Constraint_m so there is no functional change at this point. It just proves that using these previously unused bits in the encoding of the flag word doesn't break anything. The next patch will make each target preserve the current mapping of everything to Constraint_m for itself while changing the target independent implementation of the hook to return Constraint_Unknown appropriately. Each target will then be adapted in separate patches to use appropriate Constraint_* values. llvm-svn: 232093
* [X86, AVX] replace vextractf128 intrinsics with generic shufflesSanjay Patel2015-03-121-3/+0
| | | | | | | | | | | | | | | | | Now that we've replaced the vinsertf128 intrinsics, do the same for their extract twins. This is very much like D8086 (checked in at r231794): We want to replace as much custom x86 shuffling via intrinsics as possible because pushing the code down the generic shuffle optimization path allows for better codegen and less complexity in LLVM. This is also the LLVM sibling to the cfe D8275 patch. Differential Revision: http://reviews.llvm.org/D8276 llvm-svn: 232045
* Add infrastructure for support of multiple memory constraints.Daniel Sanders2015-03-121-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The operand flag word for ISD::INLINEASM nodes now contains a 15-bit memory constraint ID when the operand kind is Kind_Mem. This constraint ID is a numeric equivalent to the constraint code string and is converted with a target specific hook in TargetLowering. This patch maps all memory constraints to InlineAsm::Constraint_m so there is no functional change at this point. It just proves that using these previously unused bits in the encoding of the flag word doesn't break anything. The next patch will make each target preserve the current mapping of everything to Constraint_m for itself while changing the target independent implementation of the hook to return Constraint_Unknown appropriately. Each target will then be adapted in separate patches to use appropriate Constraint_* values. Reviewers: hfinkel Reviewed By: hfinkel Subscribers: hfinkel, jholewinski, llvm-commits Differential Revision: http://reviews.llvm.org/D8171 llvm-svn: 232027
* Handle big index in getelementptr instructionReid Kleckner2015-03-111-18/+9
| | | | | | | | | | | | | | | CodeGen incorrectly ignores (assert from APInt) constant index bigger than 2^64 in getelementptr instruction. This is a test and fix for that. Patch by Paweł Bylica! Reviewed By: rnk Subscribers: majnemer, rnk, mcrosier, resistor, llvm-commits Differential Revision: http://reviews.llvm.org/D8219 llvm-svn: 231984
* Teach lowering to correctly handle invoke statepoint and gc results tied to ↵Igor Laevsky2015-03-101-10/+29
| | | | | | | | | | | them. Note that we still can not lower gc.relocates for invoke statepoints. Also it extracts getCopyFromRegs helper function in SelectionDAGBuilder as we need to be able to customize type of the register exported from basic block during lowering of the gc.result. (Resubmitting this change after not being able to reproduce buildbot failure) Differential Revision: http://reviews.llvm.org/D7760 llvm-svn: 231800
* [X86, AVX] replace vinsertf128 intrinsics with generic shufflesSanjay Patel2015-03-101-3/+0
| | | | | | | | | | | | | | We want to replace as much custom x86 shuffling via intrinsics as possible because pushing the code down the generic shuffle optimization path allows for better codegen and less complexity in LLVM. This is the sibling patch for the Clang half of this change: http://reviews.llvm.org/D8088 Differential Revision: http://reviews.llvm.org/D8086 llvm-svn: 231794
* The operand flag word used in ISD::INLINEASM is an i32 not a pointer. NFC.Daniel Sanders2015-03-101-4/+2
| | | | | | | | | | | | | | | | | | | Summary: This is part of the work to support memory constraints that behave differently to 'm'. The subsequent patches will expand on the existing encoding (which is a 32-bit int) and as a result in some flag words will no longer fit into an i16. This problem only affected the MSP430 target which appears to have 16-bit pointers. Reviewers: hfinkel Reviewed By: hfinkel Subscribers: hfinkel, llvm-commits Differential Revision: http://reviews.llvm.org/D8168 llvm-svn: 231783
* DataLayout is mandatory, update the API to reflect it with references.Mehdi Amini2015-03-101-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Now that the DataLayout is a mandatory part of the module, let's start cleaning the codebase. This patch is a first attempt at doing that. This patch is not exactly NFC as for instance some places were passing a nullptr instead of the DataLayout, possibly just because there was a default value on the DataLayout argument to many functions in the API. Even though it is not purely NFC, there is no change in the validation. I turned as many pointer to DataLayout to references, this helped figuring out all the places where a nullptr could come up. I had initially a local version of this patch broken into over 30 independant, commits but some later commit were cleaning the API and touching part of the code modified in the previous commits, so it seemed cleaner without the intermediate state. Test Plan: Reviewers: echristo Subscribers: llvm-commits From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231740
* SelectionDAGBuilder: Merge 3 copies of the limited precision exp2 emission code.Benjamin Kramer2015-03-051-251/+93
| | | | | | NFC intended. llvm-svn: 231406
* Replace llvm.frameallocate with llvm.frameescapeReid Kleckner2015-03-051-22/+24
| | | | | | | | | | Turns out it's pretty straightforward and simplifies the implementation. Reviewers: andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D8051 llvm-svn: 231386
* Revert change r231366 as it broke clang-native-arm-cortex-a9 ↵Igor Laevsky2015-03-051-29/+10
| | | | | | Analysis/properties.m test. llvm-svn: 231374
* Teach lowering to correctly handle invoke statepoint and gc results tied to ↵Igor Laevsky2015-03-051-10/+29
| | | | | | | | them. Note that we still can not lower gc.relocates for invoke statepoints. Also it extracts getCopyFromRegs helper function in SelectionDAGBuilder as we need to be able to customize type of the register exported from basic block during lowering of the gc.result. llvm-svn: 231366
* getRegForInlineAsmConstraint wants to use TargetRegisterInfo forEric Christopher2015-02-261-11/+13
| | | | | | | | | a lookup, pass that in rather than use a naked call to getSubtargetImpl. This involved passing down and around either a TargetMachine or TargetRegisterInfo. Update all callers/definitions around the targets and SelectionDAG. llvm-svn: 230699
* ARM: treat [N x i32] and [N x i64] as AAPCS composite typesTim Northover2015-02-241-8/+7
| | | | | | | | | | | The logic is almost there already, with our special homogeneous aggregate handling. Tweaking it like this allows front-ends to emit AAPCS compliant code without ever having to count registers or add discarded padding arguments. Only arrays of i32 and i64 are needed to model AAPCS rules, but I decided to apply the logic to all integer arrays for more consistency. llvm-svn: 230348
* X86: Call __main using the SelectionDAGDavid Majnemer2015-02-211-1/+0
| | | | | | | | Synthesizing a call directly using the MI layer would confuse the frame lowering code. This is problematic as frame lowering is highly sensitive the particularities of calls, etc. llvm-svn: 230129
* Prefer SmallVector::append/insert over push_back loops.Benjamin Kramer2015-02-171-2/+1
| | | | | | Same functionality, but hoists the vector growth out of the loop. llvm-svn: 229500
* AArch64: Safely handle the incoming sret call argument.Andrew Trick2015-02-161-1/+2
| | | | | | | | | | | | | | | | | | This adds a safe interface to the machine independent InputArg struct for accessing the index of the original (IR-level) argument. When a non-native return type is lowered, we generate the hidden machine-level sret argument on-the-fly. Before this fix, we were representing this argument as OrigArgIndex == 0, which is an outright lie. In particular this crashed in the AArch64 backend where we actually try to access the type of the original argument. Now we use a sentinel value for machine arguments that have no original argument index. AArch64, ARM, Mips, and PPC now check for this case before accessing the original argument. Fixes <rdar://19792160> Null pointer assertion in AArch64TargetLowering llvm-svn: 229413
* CodeGen: Canonicalize access to function attributes, NFCDuncan P. N. Exon Smith2015-02-141-2/+1
| | | | | | | | | | | | | | | | | Canonicalize access to function attributes to use the simpler API. getAttributes().getAttribute(AttributeSet::FunctionIndex, Kind) => getFnAttribute(Kind) getAttributes().hasAttribute(AttributeSet::FunctionIndex, Kind) => hasFnAttribute(Kind) Also, add `Function::getFnStackAlignment()`, and canonicalize: getAttributes().getStackAlignment(AttributeSet::FunctionIndex) => getFnStackAlignment() llvm-svn: 229208
* MathExtras: Bring Count(Trailing|Leading)Ones and CountPopulation in line ↵Benjamin Kramer2015-02-121-3/+3
| | | | | | | | with countTrailingZeros Update all callers. llvm-svn: 228930
* Adding support for llvm.eh.begincatch and llvm.eh.endcatch intrinsics and ↵Andrew Kaylor2015-02-101-0/+3
| | | | | | | | beginning the documentation of native Windows exception handling. Differential Revision: http://reviews.llvm.org/D7398 llvm-svn: 228733
* Add a FIXME in SelectionDAGBuilder before an assert that is valid only on X86.Manuel Jacob2015-01-271-0/+3
| | | | | | | | | When lowering memcpy, memset or memmove, this assert checks whether the pointer operands are in an address space < 256 which means "user defined address space" on X86. However, this notion of "user defined address space" does not exist for other targets. llvm-svn: 227191
* Grab the TargetLowering info from the DAG rather than querying forEric Christopher2015-01-271-3/+2
| | | | | | a subtarget. llvm-svn: 227156
* Move DataLayout back to the TargetMachine from TargetSubtargetInfoEric Christopher2015-01-261-1/+1
| | | | | | | | | | | | | | | | | | | derived classes. Since global data alignment, layout, and mangling is often based on the DataLayout, move it to the TargetMachine. This ensures that global data is going to be layed out and mangled consistently if the subtarget changes on a per function basis. Prior to this all targets(*) have had subtarget dependent code moved out and onto the TargetMachine. *One target hasn't been migrated as part of this change: R600. The R600 port has, as a subtarget feature, the size of pointers and this affects global data layout. I've currently hacked in a FIXME to enable progress, but the port needs to be updated to either pass the 64-bitness to the TargetMachine, or fix the DataLayout to avoid subtarget dependent features. llvm-svn: 227113
* Revert GCStrategy ownership changesPhilip Reames2015-01-261-1/+1
| | | | | | | | | | | | This change reverts the interesting parts of 226311 (and 227046). This change introduced two problems, and I've been convinced that an alternate approach is preferrable anyways. The bugs were: - Registery appears to require all users be within the same linkage unit. After this change, asking for "statepoint-example" in Transform/ would sometimes get you nullptr, whereas asking the same question in CodeGen would return the right GCStrategy. The correct long term fix is to get rid of the utter hack which is Registry, but I don't have time for that right now. 227046 appears to have been an attempt to fix this, but I don't believe it does so completely. - GCMetadataPrinter::finishAssembly was being called more than once per GCStrategy. Each Strategy was being added to the GCModuleInfo multiple times. Once I get time again, I'm going to split GCModuleInfo into the gc.root specific part and a GCStrategy owning Analysis pass. I'm probably also going to kill off the Registry. Once that's done, I'll move the new GCStrategyAnalysis and all built in GCStrategies into Analysis. (As original suggested by Chandler.) This will accomplish my original goal of being able to access GCStrategy from Transform/ without adding all of the builtin GCs to IR/. llvm-svn: 227109
* Intrinsics: introduce llvm_any_ty aka ValueType AnyRamkumar Ramachandra2015-01-221-1/+2
| | | | | | | | | | | | | | | Specifically, gc.result benefits from this greatly. Instead of: gc.result.int.* gc.result.float.* gc.result.ptr.* ... We now have a gc.result.* that can specialize to literally any type. Differential Revision: http://reviews.llvm.org/D7020 llvm-svn: 226857
* Fixed a bug in type legalizer for masked load/store intrinsics.Elena Demikhovsky2015-01-221-2/+4
| | | | | | | | | | | | The problem occurs when after vectorization we have type <2 x i32>. This type is promoted to <2 x i64> and then requires additional efforts for expanding loads and truncating stores. I added EXPAND / TRUNCATE attributes to the masked load/store SDNodes. The code now contains additional shuffles. I've prepared changes in the cost estimation for masked memory operations, it will be submitted separately. llvm-svn: 226808
* Prevent binary-tree deterioration in sparse switch statements.Daniel Jasper2015-01-201-8/+10
| | | | | | | | | | | | | This addresses part of llvm.org/PR22262. Specifically, it prevents considering the densities of sub-ranges that have fewer than TLI.getMinimumJumpTableEntries() elements. Those densities won't help jump tables. This is not a complete solution but works around the most pressing issue. Review: http://reviews.llvm.org/D7070 llvm-svn: 226600
* Factor out a splitSwitchCase() function so that it can be reused.Daniel Jasper2015-01-201-21/+24
| | | | | | | | | | | | | | This is in preparation for a fix to llvm.org/PR22262. One of the ideas here is to first find a good jump table range first and then split before and after it. Thereby, we don't need to use the split-based-on-density heuristic at all, which can make the "binary tree" deteriorate in various cases. Also some minor cleanups. No functional changes. llvm-svn: 226551
* Move ownership of GCStrategy objects to LLVMContextPhilip Reames2015-01-161-1/+1
| | | | | | | | | | | | Note: This change ended up being slightly more controversial than expected. Chandler has tentatively okayed this for the moment, but I may be revisiting this in the near future after we settle some high level questions. Rather than have the GCStrategy object owned by the GCModuleInfo - which is an immutable analysis pass used mainly by gc.root - have it be owned by the LLVMContext. This simplifies the ownership logic (i.e. can you have two instances of the same strategy at once?), but more importantly, allows us to access the GCStrategy in the middle end optimizer. To this end, I add an accessor through Function which becomes the canonical way to get at a GCStrategy instance. In the near future, this will allows me to move some of the checks from http://reviews.llvm.org/D6808 into the Verifier itself, and to introduce optimization legality predicates for some of the recent additions to InstCombine. (These will follow as separate changes.) Differential Revision: http://reviews.llvm.org/D6811 llvm-svn: 226311
* [PM] Move TargetLibraryInfo into the Analysis library.Chandler Carruth2015-01-151-1/+1
| | | | | | | | | | | | | | | | While the term "Target" is in the name, it doesn't really have to do with the LLVM Target library -- this isn't an abstraction which LLVM targets generally need to implement or extend. It has much more to do with modeling the various runtime libraries on different OSes and with different runtime environments. The "target" in this sense is the more general sense of a target of cross compilation. This is in preparation for porting this analysis to the new pass manager. No functionality changed, and updates inbound for Clang and Polly. llvm-svn: 226078
* CodeGen support for x86_64 SEH catch handlers in LLVMReid Kleckner2015-01-141-4/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds handling for ExceptionHandling::MSVC, used by the x86_64-pc-windows-msvc triple. It assumes that filter functions have already been outlined in either the frontend or the backend. Filter functions are used in place of the landingpad catch clause type info operands. In catch clause order, the first filter to return true will catch the exception. The C specific handler table expects the landing pad to be split into one block per handler, but LLVM IR uses a single landing pad for all possible unwind actions. This patch papers over the mismatch by synthesizing single instruction BBs for every catch clause to fill in the EH selector that the landing pad block expects. Missing functionality: - Accessing data in the parent frame from outlined filters - Cleanups (from __finally) are unsupported, as they will require outlining and parent frame access - Filter clauses are unsupported, as there's no clear analogue in SEH In other words, this is the minimal set of changes needed to write IR to catch arbitrary exceptions and resume normal execution. Reviewers: majnemer Differential Revision: http://reviews.llvm.org/D6300 llvm-svn: 225904
* [StackMaps] Mark in CallLoweringInfo when lowering a patchpointHal Finkel2015-01-131-3/+4
| | | | | | | | | | | | | | | While, generally speaking, the process of lowering arguments for a patchpoint is the same as lowering a regular indirect call, on some targets it may not be exactly the same. Targets may not, for example, want to add additional register dependencies that apply only to making cross-DSO calls through linker stubs, may not want to load additional registers out of function descriptors, and may not want to add additional side-effect-causing instructions that cannot be removed later with the call itself being generated. The PowerPC target will use this in a future commit (for all of the reasons stated above). llvm-svn: 225806
* Rename llvm.recoverframeallocation to llvm.framerecoverReid Kleckner2015-01-131-3/+3
| | | | | | | | This name is less descriptive, but it sort of puts things in the 'llvm.frame...' namespace, relating it to frameallocate and frameaddress. It also avoids using "allocate" and "allocation" together. llvm-svn: 225752
OpenPOWER on IntegriCloud