aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/MachineFunction.cpp
AgeCommit message (Collapse)AuthorFilesLines
2013-02-08Revert 172027 and 174336. Remove diagnostics about over-aligned stack objects.Bob Wilson1-30/+18
Aside from the question of whether we report a warning or an error when we can't satisfy a requested stack object alignment, the current implementation of this is not good. We're not providing any source location in the diagnostics and the current warning is not connected to any warning group so you can't control it. We could improve the source location somewhat, but we can do a much better job if this check is implemented in the front-end, so let's do that instead. <rdar://problem/13127907> llvm-svn: 174741
2013-02-05Remove liveout lists from MachineRegisterInfo.Jakob Stoklund Olesen1-7/+0
All targets are now adding return value registers as implicit uses on return instructions, and there is no longer a need for the live out lists. llvm-svn: 174417
2013-02-04[Stack Alignment] emit warning instead of a hard errorManman Ren1-3/+3
Per discussion in rdar://13127907, we should emit a hard error only if people write code where the requested alignment is larger than achievable and assumes the low bits are zeros. A warning should be good enough when we are not sure if the source code assumes the low bits are zeros. rdar://13127907 llvm-svn: 174336
2013-01-10Stack Alignment: throw error if we can't satisfy the minimal alignmentManman Ren1-18/+30
requirement when creating stack objects in MachineFrameInfo. Add CreateStackObjectWithMinAlign to throw error when the minimal alignment can't be achieved and to clamp the alignment when the preferred alignment can't be achieved. Same is true for CreateVariableSizedObject. Will not emit error in CreateSpillStackObject or CreateStackObject. As long as callers of CreateStackObject do not assume the object will be aligned at the requested alignment, we should not have miscompile since later optimizations which look at the object's alignment will have the correct information. rdar://12713765 llvm-svn: 172027
2013-01-05Don't call destructors on MachineInstr and MachineOperand.Jakob Stoklund Olesen1-4/+12
The series of patches leading up to this one makes llc -O0 run 8% faster. When deallocating a MachineFunction, there is no need to visit all MachineInstr and MachineOperand objects to deallocate them. All their memory come from a BumpPtrAllocator that is about to be purged, and they have empty destructors anyway. This only applies when deallocating the MachineFunction. DeleteMachineInstr() should still be used to recycle MI memory during the codegen passes. Remove the LeakDetector support for MachineInstr. I've never seen it used before, and now it definitely doesn't work. With this patch, leaked MachineInstrs would be much less of a problem since all of their memory will be reclaimed by ~MachineFunction(). llvm-svn: 171599
2013-01-05Use ArrayRecycler for MachineInstr operand lists.Jakob Stoklund Olesen1-0/+7
Instead of an std::vector<MachineOperand>, use MachineOperand arrays from an ArrayRecycler living in MachineFunction. This has several advantages: - MachineInstr now has a trivial destructor, making it possible to delete them in batches when destroying MachineFunction. This will be enabled in a later patch. - Bypassing malloc() and free() can be faster, depending on the system library. - MachineInstr objects and their operands are allocated from the same BumpPtrAllocator, so they will usually be next to each other in memory, providing better locality of reference. - Reduce MachineInstr footprint. A std::vector is 24 bytes, the new operand array representation only uses 8+4+1 bytes in MachineInstr. - Better control over operand array reallocations. In the old representation, the use-def chains would be reordered whenever a std::vector reached its capacity. The new implementation never changes the use-def chain order. Note that some decisions in the code generator depend on the use-def chain orders, so this patch may cause different assembly to be produced in a few cases. llvm-svn: 171598
2013-01-02Move all of the header files which are involved in modelling the LLVM IRChandler Carruth1-2/+2
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-30Remove the Function::getFnAttributes method in favor of using the AttributeSetBill Wendling1-3/+5
directly. This is in preparation for removing the use of the 'Attribute' class as a collection of attributes. That will shift to the AttributeSet class instead. llvm-svn: 171253
2012-12-20Use two-arg addOperand(MF, MO) internally in MachineInstr when possible.Jakob Stoklund Olesen1-1/+1
llvm-svn: 170796
2012-12-19Rename the 'Attributes' class to 'Attribute'. It's going to represent a ↵Bill Wendling1-2/+2
single attribute in the future. llvm-svn: 170502
2012-12-04Stack Alignment: when creating stack objects in MachineFrameInfo, make sureManman Ren1-1/+24
the alignment is clamped to TargetFrameLowering.getStackAlignment if the target does not support stack realignment or the option "realign-stack" is off. This will cause miscompile if the address is treated as aligned and add is replaced with or in DAGCombine. Added a bool StackRealignable to TargetFrameLowering to check whether stack realignment is implemented for the target. Also added a bool RealignOption to MachineFrameInfo to check whether the option "realign-stack" is on. rdar://12713765 llvm-svn: 169197
2012-12-04Stack Alignment: move functions from header file MachineFrameInfo.h.Manman Ren1-0/+44
No functional change for this commit. The follow-up patch will add more stuff to these functions. rdar://12713765 llvm-svn: 169186
2012-12-03Use the new script to sort the includes of every file under lib.Chandler Carruth1-10/+10
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-01Revert the majority of the next patch in the address space series:Chandler Carruth1-2/+2
r165941: Resubmit the changes to llvm core to update the functions to support different pointer sizes on a per address space basis. Despite this commit log, this change primarily changed stuff outside of VMCore, and those changes do not carry any tests for correctness (or even plausibility), and we have consistently found questionable or flat out incorrect cases in these changes. Most of them are probably correct, but we need to devise a system that makes it more clear when we have handled the address space concerns correctly, and ideally each pass that gets updated would receive an accompanying test case that exercises that pass specificaly w.r.t. alternate address spaces. However, from this commit, I have retained the new C API entry points. Those were an orthogonal change that probably should have been split apart, but they seem entirely good. In several places the changes were very obvious cleanups with no actual multiple address space code added; these I have not reverted when I spotted them. In a few other places there were merge conflicts due to a cleaner solution being implemented later, often not using address spaces at all. In those cases, I've preserved the new code which isn't address space dependent. This is part of my ongoing effort to clean out the partial address space code which carries high risk and low test coverage, and not likely to be finished before the 3.2 release looms closer. Duncan and I would both like to see the above issues addressed before we return to these changes. llvm-svn: 167222
2012-10-15Resubmit the changes to llvm core to update the functions to support ↵Micah Villmow1-2/+2
different pointer sizes on a per address space basis. llvm-svn: 165941
2012-10-11Revert 165732 for further review.Micah Villmow1-2/+2
llvm-svn: 165747
2012-10-11Add in the first iteration of support for llvm/clang/lldb to allow variable ↵Micah Villmow1-2/+2
per address space pointer sizes to be optimized correctly. llvm-svn: 165726
2012-10-09Create enums for the different attributes.Bill Wendling1-2/+2
We use the enums to query whether an Attributes object has that attribute. The opaque layer is responsible for knowing where that specific attribute is stored. llvm-svn: 165488
2012-10-08Move TargetData to DataLayout.Micah Villmow1-6/+6
llvm-svn: 165402
2012-09-26Remove the `hasFnAttr' method from Function.Bill Wendling1-2/+2
The hasFnAttr method has been replaced by querying the Attributes explicitly. No intended functionality change. llvm-svn: 164725
2012-09-21Make the 'get*AlignmentFromAttr' functions into member functions within the ↵Bill Wendling1-2/+2
Attributes class. Now with fix. llvm-svn: 164370
2012-09-20Revert r164308 to fix buildbots.Bill Wendling1-2/+2
llvm-svn: 164309
2012-09-20Make the 'get*AlignmentFromAttr' functions into member functions within the ↵Bill Wendling1-2/+2
Attributes class. llvm-svn: 164308
2012-09-11Release build: guard dump functions withManman Ren1-4/+4
"#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)" No functional change. Update r163339. llvm-svn: 163653
2012-09-06Release build: guard dump functions with "ifndef NDEBUG"Manman Ren1-0/+8
No functional change. llvm-svn: 163339
2012-09-06Add a new optimization pass: Stack Coloring, that merges disjoint static ↵Nadav Rotem1-1/+3
allocations (allocas). Allocas are known to be disjoint if they are marked by disjoint lifetime markers (@llvm.lifetime.XXX intrinsics). llvm-svn: 163299
2012-09-05Stop casting away const qualifier needlessly.Roman Divacky1-1/+1
llvm-svn: 163258
2012-08-22Tidy up a few more uses of MF.getFunction()->getName().David Blaikie1-4/+4
Based on CR feedback from r162301 and Craig Topper's refactoring in r162347 here are a few other places that could use the same API (& in one instance drop a Function.h dependency). llvm-svn: 162367
2012-08-22Add a getName function to MachineFunction. Use it in places that previously ↵Craig Topper1-1/+6
did getFunction()->getName(). Remove includes of Function.h that are no longer needed. llvm-svn: 162347
2012-06-28Move lib/Analysis/DebugInfo.cpp to lib/VMCore/DebugInfo.cpp andBill Wendling1-1/+1
include/llvm/Analysis/DebugInfo.h to include/llvm/DebugInfo.h. The reasoning is because the DebugInfo module is simply an interface to the debug info MDNodes and has nothing to do with analysis. llvm-svn: 159312
2012-06-19Tidy up.Chad Rosier1-17/+20
llvm-svn: 158762
2012-06-19Add an ensureMaxAlignment() function to MachineFrameInfo (analogous toChad Rosier1-1/+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-03-31Teach CodeGen's version of computeMaskedBits to understand the range metadata.Rafael Espindola1-2/+3
This is the CodeGen equivalent of r153747. I tested that there is not noticeable performance difference with any combination of -O0/-O2 /-g when compiling gcc as a single compilation unit. llvm-svn: 153817
2012-03-27Print SSA and liveness tracking flags in MF::print().Jakob Stoklund Olesen1-1/+7
llvm-svn: 153518
2012-03-04Use uint16_t to store registers in callee saved register tables to reduce ↵Craig Topper1-1/+1
size of static data. llvm-svn: 151996
2012-02-06Move some llvm_unreachable's from r149849 out of switch statements to ↵Craig Topper1-2/+2
satisfy -Wcovered-switch-default llvm-svn: 149860
2012-02-05Convert assert(0) to llvm_unreachableCraig Topper1-4/+2
llvm-svn: 149816
2012-02-03Add a new MachineJumpTableInfo entry type, EK_GPRel64BlockAddress, which isAkira Hatanaka1-0/+4
needed to emit a 64-bit gp-relative relocation entry. Make changes necessary for emitting jump tables which have entries with directive .gpdword. This patch does not implement the parts needed for direct object emission or JIT. llvm-svn: 149668
2012-01-27make sure the file's matching header is #include'd first.Chris Lattner1-3/+1
llvm-svn: 149113
2012-01-27Rewrite CanShareConstantPoolEntry to be implemented in terms of theChris Lattner1-26/+26
mid-level constant folding APIs instead of doing its own analysis. This makes it more general (e.g. can now share a <2 x i64> with a <4 x i32>) and avoid duplicating a bunch of logic. llvm-svn: 149111
2012-01-26progress making the world safe to ConstantDataVector. WhileChris Lattner1-1/+4
we're at it, allow PatternMatch's "neg" pattern to match integer vector negations, and enhance ComputeNumSigned bits to handle shl of vectors. llvm-svn: 149082
2011-12-22drop unneeded config.h includesDylan Noblesmith1-1/+0
llvm-svn: 147197
2011-12-20Unweaken vtables as per ↵David Blaikie1-0/+2
http://llvm.org/docs/CodingStandards.html#ll_virtual_anch llvm-svn: 146960
2011-11-15Remove all remaining uses of Value::getNameStr().Benjamin Kramer1-1/+1
llvm-svn: 144648
2011-11-15Twinify GraphWriter a little bit.Benjamin Kramer1-2/+2
llvm-svn: 144647
2011-07-18land David Blaikie's patch to de-constify Type, with a few tweaks.Chris Lattner1-1/+1
llvm-svn: 135375
2011-06-28- Rename TargetInstrDesc, TargetOperandInfo to MCInstrDesc and MCOperandInfo andEvan Cheng1-2/+2
sink them into MC layer. - Added MCInstrInfo, which captures the tablegen generated static data. Chang TargetInstrInfo so it's based off MCInstrInfo. llvm-svn: 134021
2011-05-06Make the logic for determining function alignment more explicit. No ↵Eli Friedman1-1/+5
functionality change. llvm-svn: 131012
2011-05-02Use the PrintReg adaptor to correctly print live-in registers in debug output.Jakob Stoklund Olesen1-17/+5
llvm-svn: 130715
2011-02-22MachineConstantPoolValues are not uniqued, so they need to be freed if theyCameron Zwarich1-1/+7
share entries. Add a DenseSet to MachineConstantPool for the MachineCPVs that it owns. This will hopefully fix the MC/ARM/elf-reloc-01.ll failure on the leaks bots. llvm-svn: 126218
generated by cgit v1.1 at 2025-10-08 13:01:45 +0000