summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Record variable debug info at ISel time directly.Devang Patel2009-08-221-3/+12
| | | | llvm-svn: 79742
* Fix typo. Should check both values of RangeUse for 0. Patch by Marius Wachtler.Bill Wendling2009-08-211-1/+1
| | | | llvm-svn: 79649
* Remove a bit more cruft from the sjlj moving to a backend pass.Jim Grosbach2009-08-171-9/+0
| | | | llvm-svn: 79272
* Simplify this code to not depend as much on CurMBB.Dan Gohman2009-08-151-16/+15
| | | | llvm-svn: 79068
* Indentation change.Evan Cheng2009-08-141-2/+1
| | | | llvm-svn: 78978
* Push LLVMContexts through the IntegerType APIs.Owen Anderson2009-08-131-12/+16
| | | | llvm-svn: 78948
* Add contexts to some of the MVT APIs. No functionality change yet, just the ↵Owen Anderson2009-08-121-45/+47
| | | | | | infrastructure work needed to get the contexts to where they need to be first. llvm-svn: 78759
* Split EVT into MVT and EVT, the former representing _just_ a primitive type, ↵Owen Anderson2009-08-111-286/+286
| | | | | | | | while the latter is capable of representing either a primitive or an extended type. llvm-svn: 78713
* SjLj based exception handling unwinding support. This patch is nasty, brutishJim Grosbach2009-08-111-1/+10
| | | | | | | | | | | | | and short. Well, it's kinda short. Definitely nasty and brutish. The front-end generates the register/unregister calls into the SjLj runtime, call-site indices and landing pad dispatch. The back end fills in the LSDA with the call-site information provided by the front end. Catch blocks are not yet implemented. Built on Darwin and verified no llvm-core "make check" regressions. llvm-svn: 78625
* Rename MVT to EVT, in preparation for splitting SimpleValueType out into its ↵Owen Anderson2009-08-101-410/+410
| | | | | | own struct type. llvm-svn: 78610
* Start moving TargetLowering away from using full MVTs and towards ↵Owen Anderson2009-08-101-6/+10
| | | | | | SimpleValueType, which will simplify the privatization of IntegerType in the future. llvm-svn: 78584
* Use stripPointerCasts instead of partially rewriting it.Dale Johannesen2009-08-061-4/+2
| | | | llvm-svn: 78350
* Add assertion checks after the calls to LowerFormalArguments, LowerCall,Dan Gohman2009-08-061-1/+34
| | | | | | | and LowerReturn, to verify that the targets' hooks have respected some of their postconditions. llvm-svn: 78312
* Remove an over-aggressive assert. Functions with empty struct returnDan Gohman2009-08-061-3/+0
| | | | | | | types don't have any return values, from CodeGen's perspective. This fixes PR4688. llvm-svn: 78311
* Major calling convention code refactoring.Dan Gohman2009-08-051-229/+300
| | | | | | | | | | | | | | | | | | | Instead of awkwardly encoding calling-convention information with ISD::CALL, ISD::FORMAL_ARGUMENTS, ISD::RET, and ISD::ARG_FLAGS nodes, TargetLowering provides three virtual functions for targets to override: LowerFormalArguments, LowerCall, and LowerRet, which replace the custom lowering done on the special nodes. They provide the same information, but in a more immediately usable format. This also reworks much of the target-independent tail call logic. The decision of whether or not to perform a tail call is now cleanly split between target-independent portions, and the target dependent portion in IsEligibleForTailCallOptimization. This also synchronizes all in-tree targets, to help enable future refactoring and feature work. llvm-svn: 78142
* llvm_report_error already prints "LLVM ERROR:". So stop reporting errors ↵Benjamin Kramer2009-08-031-6/+5
| | | | | | like "LLVM ERROR: llvm: error:" or "LLVM ERROR: ERROR:". llvm-svn: 77971
* Allow target intrinsics that return multiple values, i.e., struct types,Bob Wilson2009-07-311-15/+9
| | | | | | | | | | | | | | | | | | | | | | | | in SelectionDAGLowering::visitTargetIntrinsic. This removes a bit of special-case code for vector types. After staring at it for a while, I managed to convince myself that it is not necessary. The only case where TLI.getValueType() differs from MVT::getMVT is for iPTR, so this code could potentially make a difference for a vector of pointers. But, it looks like that is not supported. Calling TLI.getValueType() on a vector of pointers leads to the following sequence of calls: TargetLowering::getValueType MVT::getMVT MVT::getVectorVT(iPTR, num elements) MVT::getExtendedVectorVT MVT::getTypeForMVT for iPTR assertion fails "Type is not extended!" So, unless I'm really missing something, this bit of code is irrelevant to the current version of LLVM, which is consistent with the fact that I don't see this code in other similar places. llvm-svn: 77747
* Move getTrue() and getFalse() to 2.5-like APIs.Owen Anderson2009-07-311-4/+4
| | | | llvm-svn: 77685
* Move types back to the 2.5 API.Owen Anderson2009-07-291-2/+2
| | | | llvm-svn: 77516
* Return ConstantVector to 2.5 API.Owen Anderson2009-07-281-1/+1
| | | | llvm-svn: 77366
* Move ConstantFP construction back to the 2.5-ish API.Owen Anderson2009-07-271-4/+2
| | | | llvm-svn: 77247
* Remove Value::getNameLenDaniel Dunbar2009-07-261-18/+6
| | | | llvm-svn: 77148
* "fix" PR4612, which is a crash on:Chris Lattner2009-07-231-1/+5
| | | | | | | | | | %0 = malloc [3758096384 x i32] The "malloc" instruction doesn't support 64-bits correctly (see PR715), and should be removed. Victor is actively working on fixing this, in the meantime just don't crash. llvm-svn: 76899
* Rename getConstantInt{True|False} to get{True|False} at Chris' behest.Owen Anderson2009-07-211-4/+4
| | | | llvm-svn: 76598
* Move a bit more state over to the LLVMContext.Owen Anderson2009-07-211-4/+6
| | | | llvm-svn: 76533
* Move stripping of bitcasts in inline asm argumentsDale Johannesen2009-07-201-0/+5
| | | | | | | to a place where it affects everything. Occurs only on calls AFAIK. llvm-svn: 76502
* Add line numbers to OProfile. To do this, I added a processDebugLoc()Jeffrey Yasskin2009-07-161-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | call to the MachineCodeEmitter interface and made copying the start line of a function not conditional on whether we're emitting Dwarf debug information. I'll propagate the processDebugLoc() calls to the non-X86 targets in a followup patch. In the long run, it'll probably be better to gather this information through the DwarfWriter, but the DwarfWriter currently depends on the AsmPrinter and TargetAsmInfo, and fixing that would be out of the way for this patch. There's a bug in OProfile 0.9.4 that makes it ignore line numbers for addresses above 4G, and a patch fixing it at http://thread.gmane.org/gmane.linux.oprofile/7634 Sample output: $ sudo opcontrol --reset; sudo opcontrol --start-daemon; sudo opcontrol --start; `pwd`/Debug/bin/lli fib.bc; sudo opcontrol --stop Signalling daemon... done Profiler running. fib(40) == 165580141 Stopping profiling. $ opreport -g -d -l `pwd`/Debug/bin/lli|head -60 Overflow stats not available CPU: Core 2, speed 1998 MHz (estimated) Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000 vma samples % linenr info image name symbol name 00007f67a30370b0 25489 61.2554 fib.c:24 10946.jo fib_left 00007f67a30370b0 1634 6.4106 fib.c:24 00007f67a30370b1 83 0.3256 fib.c:24 00007f67a30370b9 1997 7.8348 fib.c:24 00007f67a30370c6 2080 8.1604 fib.c:27 00007f67a30370c8 988 3.8762 fib.c:27 00007f67a30370cd 1315 5.1591 fib.c:27 00007f67a30370cf 251 0.9847 fib.c:27 00007f67a30370d3 1191 4.6726 fib.c:27 00007f67a30370d6 975 3.8252 fib.c:27 00007f67a30370db 1010 3.9625 fib.c:27 00007f67a30370dd 242 0.9494 fib.c:27 00007f67a30370e1 2782 10.9145 fib.c:28 00007f67a30370e5 3768 14.7828 fib.c:28 00007f67a30370eb 615 2.4128 (no location information) 00007f67a30370f3 6558 25.7287 (no location information) 00007f67a3037100 15603 37.4973 fib.c:29 10946.jo fib_right 00007f67a3037100 1646 10.5493 fib.c:29 00007f67a3037101 45 0.2884 fib.c:29 00007f67a3037109 2372 15.2022 fib.c:29 00007f67a3037116 2234 14.3178 fib.c:32 00007f67a3037118 612 3.9223 fib.c:32 00007f67a303711d 622 3.9864 fib.c:32 00007f67a303711f 385 2.4675 fib.c:32 00007f67a3037123 404 2.5892 fib.c:32 00007f67a3037126 634 4.0633 fib.c:32 00007f67a303712b 870 5.5759 fib.c:32 00007f67a303712d 62 0.3974 fib.c:32 00007f67a3037131 1848 11.8439 fib.c:33 00007f67a3037135 2840 18.2016 fib.c:33 00007f67a303713a 1 0.0064 fib.c:33 00007f67a303713b 1023 6.5564 (no location information) 00007f67a3037143 5 0.0320 (no location information) 000000000080c1e4 15 0.0360 MachineOperand.h:150 lli llvm::MachineOperand::isReg() const 000000000080c1e4 6 40.0000 MachineOperand.h:150 000000000080c1ec 2 13.3333 MachineOperand.h:150 ... llvm-svn: 76102
* Privatize the ConstantFP table. I'm on a roll!Owen Anderson2009-07-161-2/+3
| | | | llvm-svn: 76097
* Move the ConstantInt uniquing table into LLVMContextImpl. This exposed a ↵Owen Anderson2009-07-161-1/+2
| | | | | | | | number of issues in our current context-passing stuff, which is also fixed here llvm-svn: 76089
* Propagate return result extension typeAnton Korobeynikov2009-07-161-0/+7
| | | | llvm-svn: 75925
* Move a few more convenience factory functions from Constant to LLVMContext.Owen Anderson2009-07-151-1/+1
| | | | llvm-svn: 75840
* llvm_unreachable->llvm_unreachable(0), LLVM_UNREACHABLE->llvm_unreachable.Torok Edwin2009-07-141-9/+9
| | | | | | | | | This adds location info for all llvm_unreachable calls (which is a macro now) in !NDEBUG builds. In NDEBUG builds location info and the message is off (it only prints "UREACHABLE executed"). llvm-svn: 75640
* Begin the painful process of tearing apart the rat'ss nest that is ↵Owen Anderson2009-07-131-3/+4
| | | | | | | | | Constants.cpp and ConstantFold.cpp. This involves temporarily hard wiring some parts to use the global context. This isn't ideal, but it's the only way I could figure out to make this process vaguely incremental. llvm-svn: 75445
* remove llvm.part.set.* and llvm.part.select.*. They have never been Chris Lattner2009-07-121-8/+0
| | | | | | | | | | implemented in codegen, have no frontend to generate them, and are better implemented with pattern matching (like the ppc backend does to generate rlwimi/rlwinm etc). PR4543 llvm-svn: 75430
* assert(0) -> LLVM_UNREACHABLE.Torok Edwin2009-07-111-7/+7
| | | | | | | | | Make llvm_unreachable take an optional string, thus moving the cerr<< out of line. LLVM_UNREACHABLE is now a simple wrapper that makes the message go away for NDEBUG builds. llvm-svn: 75379
* Convert more assert(0)+abort() -> LLVM_UNREACHABLE,Torok Edwin2009-07-111-24/+17
| | | | | | and abort()/exit() -> llvm_report_error(). llvm-svn: 75363
* Fix an apparent copy-and-paste problem in an error message.Bob Wilson2009-07-091-1/+1
| | | | llvm-svn: 75197
* Thread LLVMContext through MVT and related parts of SDISel.Owen Anderson2009-07-091-2/+2
| | | | llvm-svn: 75153
* Remove the vicmp and vfcmp instructions. Because we never had a release withNick Lewycky2009-07-081-27/+0
| | | | | | | these instructions, no autoupgrade or backwards compatibility support is provided. llvm-svn: 74991
* lower vector icmp/fcmp to ICMP/FCMP nodes with the right resultChris Lattner2009-07-071-2/+5
| | | | | | (vector of bool). llvm-svn: 74960
* Add NumFixedArgs attribute to CallSDNode which indicates the number of fixed ↵Tilmann Scheller2009-07-031-5/+5
| | | | | | | | | | | arguments in a vararg call. With the SVR4 ABI on PowerPC, vector arguments for vararg calls are passed differently depending on whether they are a fixed or a variable argument. Variable vector arguments always go into memory, fixed vector arguments are put into vector registers. If there are no free vector registers available, fixed vector arguments are put on the stack. The NumFixedArgs attribute allows to decide for an argument in a vararg call whether it belongs to the fixed or variable portion of the parameter list. llvm-svn: 74764
* Simplify debug info intrisinc lowering.Devang Patel2009-07-021-96/+66
| | | | llvm-svn: 74733
* Simplify. Devang Patel2009-07-021-1/+0
| | | | llvm-svn: 74677
* Simplify. No intentional functionality change.Devang Patel2009-07-021-49/+36
| | | | llvm-svn: 74673
* Refactor. No functionality change.Devang Patel2009-07-011-10/+4
| | | | llvm-svn: 74659
* Change this from an assert to a cerr+exit, since it's diagnosing anDan Gohman2009-06-151-2/+6
| | | | | | unsupported inline asm construct, rather than verifying a code invariant. llvm-svn: 73435
* Split the Add, Sub, and Mul instruction opcodes into separateDan Gohman2009-06-041-32/+14
| | | | | | | | | | | | | | | integer and floating-point opcodes, introducing FAdd, FSub, and FMul. For now, the AsmParser, BitcodeReader, and IRBuilder all preserve backwards compatability, and the Core LLVM APIs preserve backwards compatibility for IR producers. Most front-ends won't need to change immediately. This implements the first step of the plan outlined here: http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt llvm-svn: 72897
* Add a new codegen pass that normalizes dwarf exception handlingDuncan Sands2009-05-221-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | code in preparation for code generation. The main thing it does is handle the case when eh.exception calls (and, in a future patch, eh.selector calls) are far away from landing pads. Right now in practice you only find eh.exception calls close to landing pads: either in a landing pad (the common case) or in a landing pad successor, due to loop passes shifting them about. However future exception handling improvements will result in calls far from landing pads: (1) Inlining of rewinds. Consider the following case: In function @f: ... invoke @g to label %normal unwind label %unwinds ... unwinds: %ex = call i8* @llvm.eh.exception() ... In function @g: ... invoke @something to label %continue unwind label %handler ... handler: %ex = call i8* @llvm.eh.exception() ... perform cleanups ... "rethrow exception" Now inline @g into @f. Currently this is turned into: In function @f: ... invoke @something to label %continue unwind label %handler ... handler: %ex = call i8* @llvm.eh.exception() ... perform cleanups ... invoke "rethrow exception" to label %normal unwind label %unwinds unwinds: %ex = call i8* @llvm.eh.exception() ... However we would like to simplify invoke of "rethrow exception" into a branch to the %unwinds label. Then %unwinds is no longer a landing pad, and the eh.exception call there is then far away from any landing pads. (2) Using the unwind instruction for cleanups. It would be nice to have codegen handle the following case: invoke @something to label %continue unwind label %run_cleanups ... handler: ... perform cleanups ... unwind This requires turning "unwind" into a library call, which necessarily takes a pointer to the exception as an argument (this patch also does this unwind lowering). But that means you are using eh.exception again far from a landing pad. (3) Bugpoint simplifications. When bugpoint is simplifying exception handling code it often generates eh.exception calls far from a landing pad, which then causes codegen to assert. Bugpoint then latches on to this assertion and loses sight of the original problem. Note that it is currently rare for this pass to actually do anything. And in fact it normally shouldn't do anything at all given the code coming out of llvm-gcc! But it does fire a few times in the testsuite. As far as I can see this is almost always due to the LoopStrengthReduce codegen pass introducing pointless loop preheader blocks which are landing pads and only contain a branch to another block. This other block contains an eh.exception call. So probably by tweaking LoopStrengthReduce a bit this can be avoided. llvm-svn: 72276
* Temporarily revert r72191. It was causing an assert during llvm-gccBill Wendling2009-05-211-40/+13
| | | | | | bootstrapping. llvm-svn: 72200
* Introduce DebugScope which gets embedded into the machine instructions' ↵Argyrios Kyrtzidis2009-05-201-13/+40
| | | | | | | | DebugLoc. DebugScope refers to a debug region, function or block. llvm-svn: 72191
OpenPOWER on IntegriCloud