summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/MachineFunction.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Make isAliased property for fixed-offset stack objects adjustableHal Finkel2014-08-161-5/+7
| | | | | | | | | | | | | | | | | | | | We used to assume that any fixed-offset stack object was not aliased. This meant that no IR value could point to the memory contained in such an object. This is a reasonable default, but is not a universally-correct target-independent fact. For example, on PowerPC (both Darwin and non-Darwin), some byval arguments are allocated at fixed offsets by the ABI. These, however, certainly can be pointed to by IR values. This change moves the 'isAliased' logic out of FixedStackPseudoSourceValue and into MFI, and allows the isAliased property to be overridden for fixed-offset objects. This will be used by an upcoming commit to the PowerPC backend to fix PR20280. No functionality change intended (the behavior of FixedStackPseudoSourceValue::isAliased has been made more conservative for callers that don't pass an MFI object, but I don't see any in-tree callers that do that). llvm-svn: 215794
* Have MachineRegisterInfo take and store the MachineFunction itEric Christopher2014-08-121-1/+1
| | | | | | | | was created for rather than the TargetMachine since we only needed the TM for the subtarget and we can get that from the MF. llvm-svn: 215432
* Have MachineFunction cache a pointer to the subtarget to make lookupsEric Christopher2014-08-051-12/+9
| | | | | | | | | | | shorter/easier and have the DAG use that to do the same lookup. This can be used in the future for TargetMachine based caching lookups from the MachineFunction easily. Update the MIPS subtarget switching machinery to update this pointer at the same time it runs. llvm-svn: 214838
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-041-13/+20
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* AA metadata refactoring (introduce AAMDNodes)Hal Finkel2014-07-241-4/+4
| | | | | | | | | | | | | | | | | | | | In order to enable the preservation of noalias function parameter information after inlining, and the representation of block-level __restrict__ pointer information (etc.), additional kinds of aliasing metadata will be introduced. This metadata needs to be carried around in AliasAnalysis::Location objects (and MMOs at the SDAG level), and so we need to generalize the current scheme (which is hard-coded to just one TBAA MDNode*). This commit introduces only the necessary refactoring to allow for the introduction of other aliasing metadata types, but does not actually introduce any (that will come in a follow-up commit). What it does introduce is a new AAMDNodes structure to hold all of the aliasing metadata nodes associated with a particular memory-accessing instruction, and uses that structure instead of the raw MDNode* in AliasAnalysis::Location, etc. No functionality change intended. llvm-svn: 213859
* CodeGen: Add a getSectionKind method to MachineConstantPoolEntryDavid Majnemer2014-07-141-0/+31
| | | | | | This is just a helper routine, no functionality has changed. llvm-svn: 212993
* Revert "Introduce a string_ostream string builder facilty"Alp Toker2014-06-261-2/+3
| | | | | | Temporarily back out commits r211749, r211752 and r211754. llvm-svn: 211814
* Introduce a string_ostream string builder faciltyAlp Toker2014-06-261-3/+2
| | | | | | | | | | | | | | | | | | | | string_ostream is a safe and efficient string builder that combines opaque stack storage with a built-in ostream interface. small_string_ostream<bytes> additionally permits an explicit stack storage size other than the default 128 bytes to be provided. Beyond that, storage is transferred to the heap. This convenient class can be used in most places an std::string+raw_string_ostream pair or SmallString<>+raw_svector_ostream pair would previously have been used, in order to guarantee consistent access without byte truncation. The patch also converts much of LLVM to use the new facility. These changes include several probable bug fixes for truncated output, a programming error that's no longer possible with the new interface. llvm-svn: 211749
* Re-apply r211399, "Generate native unwind info on Win64" with a fix to ↵NAKAMURA Takumi2014-06-251-0/+15
| | | | | | | | | | | | | | | | | | | | | | | ignore SEH pseudo ops in X86 JIT emitter. -- This patch enables LLVM to emit Win64-native unwind info rather than DWARF CFI. It handles all corner cases (I hope), including stack realignment. Because the unwind info is not flexible enough to describe stack frames with a gap of unknown size in the middle, such as the one caused by stack realignment, I modified register spilling code to place all spills into the fixed frame slots, so that they can be accessed relative to the frame pointer. Patch by Vadim Chugunov! Reviewed By: rnk Differential Revision: http://reviews.llvm.org/D4081 llvm-svn: 211691
* Reformat.NAKAMURA Takumi2014-06-251-17/+13
| | | | llvm-svn: 211689
* Revert r211399, "Generate native unwind info on Win64"NAKAMURA Takumi2014-06-221-28/+17
| | | | | | It broke Legacy JIT Tests on x86_64-{mingw32|msvc}, aka Windows x64. llvm-svn: 211480
* Generate native unwind info on Win64Reid Kleckner2014-06-201-17/+28
| | | | | | | | | | | | | | | | | | | | This patch enables LLVM to emit Win64-native unwind info rather than DWARF CFI. It handles all corner cases (I hope), including stack realignment. Because the unwind info is not flexible enough to describe stack frames with a gap of unknown size in the middle, such as the one caused by stack realignment, I modified register spilling code to place all spills into the fixed frame slots, so that they can be accessed relative to the frame pointer. Patch by Vadim Chugunov! Reviewed By: rnk Differential Revision: http://reviews.llvm.org/D4081 llvm-svn: 211399
* Convert several loops over MachineFunction basic blocks to range-based loopsAlexey Samsonov2014-04-301-2/+2
| | | | llvm-svn: 207683
* [Modules] Make Support/Debug.h modular. This requires it to not changeChandler Carruth2014-04-211-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | behavior based on other files defining DEBUG_TYPE, which means it cannot define DEBUG_TYPE at all. This is actually better IMO as it forces folks to define relevant DEBUG_TYPEs for their files. However, it requires all files that currently use DEBUG(...) to define a DEBUG_TYPE if they don't already. I've updated all such files in LLVM and will do the same for other upstream projects. This still leaves one important change in how LLVM uses the DEBUG_TYPE macro going forward: we need to only define the macro *after* header files have been #include-ed. Previously, this wasn't possible because Debug.h required the macro to be pre-defined. This commit removes that. By defining DEBUG_TYPE after the includes two things are fixed: - Header files that need to provide a DEBUG_TYPE for some inline code can do so by defining the macro before their inline code and undef-ing it afterward so the macro does not escape. - We no longer have rampant ODR violations due to including headers with different DEBUG_TYPE definitions. This may be mostly an academic violation today, but with modules these types of violations are easy to check for and potentially very relevant. Where necessary to suppor headers with DEBUG_TYPE, I have moved the definitions below the includes in this commit. I plan to move the rest of the DEBUG_TYPE macros in LLVM in subsequent commits; this one is big enough. The comments in Debug.h, which were hilariously out of date already, have been updated to reflect the recommended practice going forward. llvm-svn: 206822
* Break PseudoSourceValue out of the Value hierarchy. It is now the root of ↵Nick Lewycky2014-04-151-1/+7
| | | | | | its own tree containing FixedStackPseudoSourceValue (which you can use isa/dyn_cast on) and MipsCallEntry (which you can't). Anything that needs to use either a PseudoSourceValue* and Value* is strongly encouraged to use a MachinePointerInfo instead. llvm-svn: 206255
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-141-7/+7
| | | | | | instead of comparing to nullptr. llvm-svn: 206142
* Move the segmented stack switch to a function attributeReid Kleckner2014-04-101-0/+5
| | | | | | | | | This removes the -segmented-stacks command line flag in favor of a per-function "split-stack" attribute. Patch by Luqman Aden and Alex Crichton! llvm-svn: 205997
* Make consistent use of MCPhysReg instead of uint16_t throughout the tree.Craig Topper2014-04-041-1/+1
| | | | llvm-svn: 205610
* [Layering] Move DebugInfo.h into the IR library where its implementationChandler Carruth2014-03-061-1/+1
| | | | | | already lives. llvm-svn: 203046
* [C++11] Replace llvm::next and llvm::prior with std::next and std::prev.Benjamin Kramer2014-03-021-2/+2
| | | | | | Remove the old functions. llvm-svn: 202636
* Put the functionality for printing a value to a raw_ostream as anChandler Carruth2014-01-091-2/+1
| | | | | | | | | | | | operand into the Value interface just like the core print method is. That gives a more conistent organization to the IR printing interfaces -- they are all attached to the IR objects themselves. Also, update all the users. This removes the 'Writer.h' header which contained only a single function declaration. llvm-svn: 198836
* Move the LLVM IR asm writer header files into the IR directory, as theyChandler Carruth2014-01-071-1/+1
| | | | | | | | | | | | | | | | | are part of the core IR library in order to support dumping and other basic functionality. Rename the 'Assembly' include directory to 'AsmParser' to match the library name and the only functionality left their -- printing has been in the core IR library for quite some time. Update all of the #includes to match. All of this started because I wanted to have the layering in good shape before I started adding support for printing LLVM IR using the new pass infrastructure, and commandline support for the new pass infrastructure. llvm-svn: 198688
* Make the llvm mangler depend only on DataLayout.Rafael Espindola2014-01-031-5/+5
| | | | | | | | | | | | | | Before this patch any program that wanted to know the final symbol name of a GlobalValue had to link with Target. This patch implements a compromise solution where the mangler uses DataLayout. This way, any tool that already links with Target (llc, clang) gets the exact behavior as before and new IR files can be mangled without linking with Target. With this patch the mangler is constructed with just a DataLayout and DataLayout is extended to include the information the Mangler needs. llvm-svn: 198438
* [stackprotector] Use analysis from the StackProtector pass for stack layout ↵Josh Magee2013-12-191-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | in PEI a nd LocalStackSlot passes. This changes the MachineFrameInfo API to use the new SSPLayoutKind information produced by the StackProtector pass (instead of a boolean flag) and updates a few pass dependencies (to preserve the SSP analysis). The stack layout follows the same approach used prior to this change - i.e., only LargeArray stack objects will be placed near the canary and everything else will be laid out normally. After this change, structures containing large arrays will also be placed near the canary - a case previously missed by the old implementation. Out of tree targets will need to update their usage of MachineFrameInfo::CreateStackObject to remove the MayNeedSP argument. The next patch will implement the rules for sspstrong and sspreq. The end goal is to support ssp-strong stack layout rules. WIP. Differential Revision: http://llvm-reviews.chandlerc.com/D2158 llvm-svn: 197653
* Fix an over-constrained assertion in MachineFunction::addLiveIn.Quentin Colombet2013-12-121-1/+10
| | | | | | | | | | | | | | | | The assertion was checking that the virtual register VReg used to represent the physical register PReg uses the same register class as the one passed to MachineFunction::addLiveIn. This is over-constraining because it is sufficient to check that the register class of VReg (VRegRC) is a subclass of the register class of PReg (PRegRC) and that VRegRC contains PReg. Indeed, if VReg gets constrained because of some operation constraints between two calls of MachineFunction::addLiveIn, the original assertion cannot match. This fixes <rdar://problem/15633429>. llvm-svn: 197097
* Use function attributes to indicate that we don't want to realign the stack.Bill Wendling2013-08-011-1/+2
| | | | | | | | Function attributes are the future! So just query whether we want to realign the stack directly from the function instead of through a random target options structure. llvm-svn: 187618
* Directly access objects which may change during compilation.Bill Wendling2013-06-171-16/+37
| | | | llvm-svn: 184121
* Print ConstantPool entries initialized to Values with WriteAsOperand instead ofDan Gohman2013-06-121-1/+2
| | | | | | | operator<< so that functions are printed as just their name instead of as their entire definition, which is excessively verbose in this context. llvm-svn: 183871
* Move estimateStackSize from ARM into MachineFrameInfoHal Finkel2013-03-141-0/+48
| | | | | | | | | | This is a generic function (derived from PEI); moving it into MachineFrameInfo eliminates a current redundancy between the ARM and AArch64 backends, and will allow it to be used by the PowerPC target code. No functionality change intended. llvm-svn: 177111
* Revert 172027 and 174336. Remove diagnostics about over-aligned stack objects.Bob Wilson2013-02-081-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
* Remove liveout lists from MachineRegisterInfo.Jakob Stoklund Olesen2013-02-051-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
* [Stack Alignment] emit warning instead of a hard errorManman Ren2013-02-041-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
* Stack Alignment: throw error if we can't satisfy the minimal alignmentManman Ren2013-01-101-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
* Don't call destructors on MachineInstr and MachineOperand.Jakob Stoklund Olesen2013-01-051-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
* Use ArrayRecycler for MachineInstr operand lists.Jakob Stoklund Olesen2013-01-051-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
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-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
* Remove the Function::getFnAttributes method in favor of using the AttributeSetBill Wendling2012-12-301-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
* Use two-arg addOperand(MF, MO) internally in MachineInstr when possible.Jakob Stoklund Olesen2012-12-201-1/+1
| | | | llvm-svn: 170796
* Rename the 'Attributes' class to 'Attribute'. It's going to represent a ↵Bill Wendling2012-12-191-2/+2
| | | | | | single attribute in the future. llvm-svn: 170502
* Stack Alignment: when creating stack objects in MachineFrameInfo, make sureManman Ren2012-12-041-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
* Stack Alignment: move functions from header file MachineFrameInfo.h.Manman Ren2012-12-041-0/+44
| | | | | | | | | No functional change for this commit. The follow-up patch will add more stuff to these functions. rdar://12713765 llvm-svn: 169186
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-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
* Revert the majority of the next patch in the address space series:Chandler Carruth2012-11-011-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
* Resubmit the changes to llvm core to update the functions to support ↵Micah Villmow2012-10-151-2/+2
| | | | | | different pointer sizes on a per address space basis. llvm-svn: 165941
* Revert 165732 for further review.Micah Villmow2012-10-111-2/+2
| | | | llvm-svn: 165747
* Add in the first iteration of support for llvm/clang/lldb to allow variable ↵Micah Villmow2012-10-111-2/+2
| | | | | | per address space pointer sizes to be optimized correctly. llvm-svn: 165726
* Create enums for the different attributes.Bill Wendling2012-10-091-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
* Move TargetData to DataLayout.Micah Villmow2012-10-081-6/+6
| | | | llvm-svn: 165402
* Remove the `hasFnAttr' method from Function.Bill Wendling2012-09-261-2/+2
| | | | | | | The hasFnAttr method has been replaced by querying the Attributes explicitly. No intended functionality change. llvm-svn: 164725
* Make the 'get*AlignmentFromAttr' functions into member functions within the ↵Bill Wendling2012-09-211-2/+2
| | | | | | Attributes class. Now with fix. llvm-svn: 164370
OpenPOWER on IntegriCloud