summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* Add warning capabilities in LLVM.Quentin Colombet2013-12-161-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch adds a new LLVMContext::diagnose that can be used to communicate to the front-end, if any, that something of interest happened. The diagnostics are supported by a new abstraction, the DiagnosticInfo class. The base class contains the following information: - The kind of the report: What this is about. - The severity of the report: How bad this is. This patch also adds 2 classes: - DiagnosticInfoInlineAsm: For inline asm reporting. Basically, this diagnostic will be used to switch to the new diagnostic API for LLVMContext::emitError. - DiagnosticStackSize: For stack size reporting. Comes as a replacement of the hard coded warning in PEI. This patch also features dynamic diagnostic identifiers. In other words plugins can use this infrastructure for their own diagnostics (for more details, see getNextAvailablePluginDiagnosticKind). This patch introduces a new DiagnosticHandlerTy and a new DiagnosticContext in the LLVMContext that should be set by the front-end to be able to map these diagnostics in its own system. http://llvm-reviews.chandlerc.com/D2376 <rdar://problem/15515174> llvm-svn: 197438
* Revert "Allow MachineCSE to coalesce trivial subregister copies the same way ↵Rafael Espindola2013-12-162-35/+9
| | | | | | | | | | that it coalesces normal copies." This reverts commit r197414. It broke the ppc64 bootstrap. I will post a testcase in a sec. llvm-svn: 197424
* Allow MachineCSE to coalesce trivial subregister copies the same wayAndrew Trick2013-12-162-9/+35
| | | | | | | | | | | | | | | | | that it coalesces normal copies. Without this, MachineCSE is powerless to handle redundant operations with truncated source operands. This required fixing the 2-addr pass to handle tied subregisters. It isn't clear what combinations of subregisters can legally be tied, but the simple case of truncated source operands is now safely handled: %vreg11<def> = COPY %vreg1:sub_32bit; GR32:%vreg11 GR64:%vreg1 %vreg12<def> = COPY %vreg2:sub_32bit; GR32:%vreg12 GR64:%vreg2 %vreg13<def,tied1> = ADD32rr %vreg11<tied0>, %vreg12<kill>, %EFLAGS<imp-def> llvm-svn: 197414
* whitespaceAndrew Trick2013-12-161-1/+1
| | | | llvm-svn: 197413
* [Stackmap] Refactor operand parsing.Juergen Ributzka2013-12-141-91/+74
| | | | llvm-svn: 197329
* Remove weak vtables. No functional change.Juergen Ributzka2013-12-144-1/+9
| | | | llvm-svn: 197323
* [Stackmap] Liveness Analysis PassJuergen Ributzka2013-12-147-14/+255
| | | | | | | | | | | | | | | | | | | | This optional register liveness analysis pass can be enabled with either -enable-stackmap-liveness, -enable-patchpoint-liveness, or both. The pass traverses each basic block in a machine function. For each basic block the instructions are processed in reversed order and if a patchpoint or stackmap instruction is encountered the current live-out register set is encoded as a register mask and attached to the instruction. Later on during stackmap generation the live-out register mask is processed and also emitted as part of the stackmap. This information is optional and intended for optimization purposes only. This will enable a client of the stackmap to reason about the registers it can use and which registers need to be preserved. Reviewed by Andy llvm-svn: 197317
* Convert register liveness tracking to work on a sub-register level instead ↵Juergen Ributzka2013-12-145-146/+145
| | | | | | | | of just register units. Reviewed by Andy llvm-svn: 197315
* [block-freq] Rename getEntryFrequency() -> getEntryFreq() to match ↵Michael Gottesman2013-12-144-5/+5
| | | | | | getBlockFreq() in all *BlockFrequencyInfo*. llvm-svn: 197304
* [block-freq] Refactor LiveInterals::getSpillWeight to use the new ↵Michael Gottesman2013-12-144-8/+10
| | | | | | | | | | | | | | | | | | | | | | | MachineBlockFrequencyInfo methods. This is slightly more interesting than the previous batch of changes. Specifically: 1. We refactor getSpillWeight to take a MachineBlockFrequencyInfo (MBFI) object. This enables us to completely encapsulate the actual manner we use the MachineBlockFrequencyInfo to get our spill weights. This yields cleaner code since one does not need to fetch the actual block frequency before getting the spill weight if all one wants it the spill weight. It also gives us access to entry frequency which we need for our computation. 2. Instead of having getSpillWeight take a MachineBasicBlock (as one might think) to look up the block frequency via the MBFI object, we instead take in a MachineInstr object. The reason for this is that the method is supposed to return the spill weight for an instruction according to the comments around the function. llvm-svn: 197296
* [block-freq] Store MBFI as a field on SpillPlacement so we can access it to ↵Michael Gottesman2013-12-142-3/+5
| | | | | | get the entry frequency while processing data. llvm-svn: 197291
* [block-freq] Update MachineBlockPlacement and RegAllocGreedy to use the new ↵Michael Gottesman2013-12-142-9/+13
| | | | | | MachineBlockFrequencyInfo methods. llvm-svn: 197290
* [block-freq] Update BlockFrequencyInfo/MachineBlockFrequencyInfo to use the ↵Michael Gottesman2013-12-141-1/+1
| | | | | | new print methods. llvm-svn: 197289
* Print the address space of a MachineMemOperandMatt Arsenault2013-12-141-0/+4
| | | | llvm-svn: 197288
* [block-freq] Add the equivalent methods to MachineBlockFrequencyInfo and ↵Michael Gottesman2013-12-141-0/+16
| | | | | | BlockFrequencyInfo that were added to BlockFrequencyImpl in r197285 and r197284. llvm-svn: 197287
* comment typo.Andrew Trick2013-12-131-1/+1
| | | | llvm-svn: 197278
* DebugInfo: Move type units into the debug_types section with appropriate ↵David Blaikie2013-12-133-9/+45
| | | | | | | | | | | | | | | | | | | | | | | | comdat grouping and type unit headers This commit does not complete the type units feature - there are issues around fission support (skeletal type units, pubtypes/pubnames) and hashing of some types including those containing references to types in other type units. Originally committed as r197073 and reverted in r197079. Recommitted as r197197 to reproduce the failure and reverted as r197199 Turns out there was unstable ordering in the type unit dumping code. Fixed by using MapVector in DWARFContext to store the debug_types comdat sections. Recommitted as r197210 with a fix to dumping and reverted as r197211 because I was a bit gun shy and thought I saw a failure that turned out to be unrelated. So here we go - once more with feeling! \o/ llvm-svn: 197275
* Revert "Convert liveness tracking to work on a sub-register level instead of ↵Andrew Trick2013-12-135-122/+146
| | | | | | | | | | just register units." This reverts commit r197253. This was a great change, but Juergen should be the commit author. llvm-svn: 197262
* Revert "Liveness Analysis Pass"Andrew Trick2013-12-137-253/+14
| | | | | | | | | | | | | | This reverts commit r197254. This was an accidental merge of Juergen's patch. It will be checked in shortly, but wasn't meant to go in quite yet. Conflicts: include/llvm/CodeGen/StackMaps.h lib/CodeGen/StackMaps.cpp test/CodeGen/X86/stackmap-liveness.ll llvm-svn: 197260
* Grow the stackmap/patchpoint format to hold 64-bit IDs.Andrew Trick2013-12-132-9/+8
| | | | llvm-svn: 197255
* Liveness Analysis PassAndrew Trick2013-12-137-13/+252
| | | | llvm-svn: 197254
* Convert liveness tracking to work on a sub-register level instead of just ↵Andrew Trick2013-12-135-146/+122
| | | | | | register units. llvm-svn: 197253
* Revert "DebugInfo: Move type units into the debug_types section with ↵David Blaikie2013-12-133-45/+9
| | | | | | | | appropriate comdat grouping and type unit headers" This reverts commit r197210. llvm-svn: 197211
* DebugInfo: Move type units into the debug_types section with appropriate ↵David Blaikie2013-12-133-9/+45
| | | | | | | | | | | | | | | | | | comdat grouping and type unit headers This commit does not complete the type units feature - there are issues around fission support (skeletal type units, pubtypes/pubnames) and hashing of some types including those containing references to types in other type units. Originally committed as r197073 and reverted in r197079. Recommitted as r197197 to reproduce the failure and reverted as r197199 Turns out there was unstable ordering in the type unit dumping code. Fixed by using MapVector in DWARFContext to store the debug_types comdat sections. llvm-svn: 197210
* Revert "DebugInfo: Move type units into the debug_types section with ↵David Blaikie2013-12-133-45/+9
| | | | | | | | appropriate comdat grouping and type unit headers" This reverts commit r197197. llvm-svn: 197199
* DebugInfo: Move type units into the debug_types section with appropriate ↵David Blaikie2013-12-133-9/+45
| | | | | | | | | | | | | | | | | | | comdat grouping and type unit headers This commit does not complete the type units feature - there are issues around fission support (skeletal type units, pubtypes/pubnames) and hashing of some types including those containing references to types in other type units. Originally committed as r197073 and reverted in r197079. This commit originally got jumbled up with another build-breaking commit and I can't find the failures I thought this caused anymore. Recommitting to hopefully get some clean buildbot results to work from. I have a sneaking suspicion there's unstable output in the comdat group output of MCStreamer... llvm-svn: 197197
* 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
* Add two additional hazard recognizer functionsHal Finkel2013-12-111-7/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds two additional functions to the hazard recognizer interface. These are optional (in the sense that the default implementations preserve the current behavior), and used by the post-RA scheduler. Upcoming commits will use this functionality in order to improve dispatch-group formation on the POWER7 and related cores. Dispatch groups are an odd construct: sometimes we need to insert nops to force a new one to start (for performance reasons), and some instructions need to appear in certain positions within a group, but the groups are not fundamentally cycle based (they can contain instructions with data dependencies with non-trivial latencies). Motivation: unsigned PreEmitNoops(SUnit *) - Used to force the post-RA scheduler to insert nops to force a new dispatch group to begin. We already have a NoopHazard, and this is also still needed. However, NoopHazard only causes a nop to be inserted if there are no other available instructions, and so is not always sufficient. The number of nops to insert depends on state that only the hazard recognizer has, so a general callback is necessary. bool ShouldPreferAnother(SUnit *) - Used to avoid scheduling instructions that would start a new dispatch group when others are available that could be part of the current dispatch group. In this case, we don't want to issue nops, because the non-preferred instruction will implicitly start a new dispatch group regardless. Although the motivation for these functions is driven by the PowerPC backend, they are completely general. llvm-svn: 197084
* On ELF and COFF treat linker_private like private.Rafael Espindola2013-12-111-1/+1
| | | | | | | | The linkers on these systems don't have anything special to do with these symbols. Since the intent is for them to be absent from the final object, just treat them as private. llvm-svn: 197080
* Revert "DebugInfo: Move type units into the debug_types section with ↵David Blaikie2013-12-113-45/+9
| | | | | | | | | | | | appropriate comdat grouping and type unit headers" This reverts commit r197073. The test seems to be failing on some buildbots for unknown reasons. Reverting until I can figure that out. If anyone's got a reproduction (.s and .o together would be great) - I'd really appreciate it. llvm-svn: 197079
* DebugInfo: Move type units into the debug_types section with appropriate ↵David Blaikie2013-12-113-9/+45
| | | | | | | | | | | comdat grouping and type unit headers This commit does not complete the type units feature - there are issues around fission support (skeletal type units, pubtypes/pubnames) and hashing of some types including those containing references to types in other type units. llvm-svn: 197073
* DwarfUnit: LLVM_OVERRIDE and constify some functionsDavid Blaikie2013-12-112-4/+4
| | | | llvm-svn: 197072
* SelectionDAG: Fix a typo.Benjamin Kramer2013-12-111-1/+1
| | | | | | Found by "cppcheck". PR18208. llvm-svn: 197047
* Extend (truncate (load)) foldingRichard Sandiford2013-12-111-0/+14
| | | | | | | | | DAGCombiner could fold (truncate (load)) -> smaller load if the original load was the width of the truncation result or wider. This patch extends it to handle cases where the original load was narrower (and so the extension type stays the same). llvm-svn: 197030
* Add TargetRegisterInfo::reverseLocalAssignment hook.Andrew Trick2013-12-111-1/+8
| | | | | | | | | | | | | | This hook reverses the order of assignment for local live ranges. This will generally allocate shorter local live ranges first. For targets with many registers, this could reduce regalloc compile time by a large factor. It should still achieve optimal coloring; however, it can change register eviction decisions. It is disabled by default for two reasons: (1) Top-down allocation is simpler and easier to debug for targets that don't benefit from reversing the order. (2) Bottom-up allocation could result in poor evicition decisions on some targets affecting the performance of compiled code. llvm-svn: 197001
* Prune redundant dependencies in LLVMBuild.txt.NAKAMURA Takumi2013-12-111-1/+1
| | | | llvm-svn: 196988
* on darwin<10, fallback to .weak_definition (PPC,X86)David Fang2013-12-101-1/+2
| | | | | | .weak_def_can_be_hidden was not yet supported by the system assembler llvm-svn: 196970
* Fix gcc warnings.Matt Arsenault2013-12-101-0/+2
| | | | | | Unused variable and unused typedef in release build. llvm-svn: 196947
* Reland "Fix miscompile of MS inline assembly with stack realignment"Reid Kleckner2013-12-102-5/+15
| | | | | | | | | | | This re-lands commit r196876, which was reverted in r196879. The tests have been fixed to pass on platforms with a stack alignment larger than 4. Update to clang side tests will land shortly. llvm-svn: 196939
* Add TargetLowering::prepareVolatileOrAtomicLoadRichard Sandiford2013-12-101-1/+6
| | | | | | | | | | | | | | | | | One unusual feature of the z architecture is that the result of a previous load can be reused indefinitely for subsequent loads, even if a cache-coherent store to that location is performed by another CPU. A special serializing instruction must be used if you want to force a load to be reattempted. Since volatile loads are not supposed to be omitted in this way, we should insert a serializing instruction before each such load. The same goes for atomic loads. The patch implements this at the IR->DAG boundary, in a similar way to atomic fences. It is a no-op for targets other than SystemZ. llvm-svn: 196905
* Add proper dependencies to LLVMBuild.txt in llvm/lib.NAKAMURA Takumi2013-12-101-1/+1
| | | | | | I'll prune redundant deps in LLVMBuild.txt, later. llvm-svn: 196881
* Revert "Fix miscompile of MS inline assembly with stack realignment"Reid Kleckner2013-12-102-15/+5
| | | | | | | This reverts commit r196876. Its tests failed on the bots, so I'll figure it out tomorrow. llvm-svn: 196879
* Fix miscompile of MS inline assembly with stack realignmentReid Kleckner2013-12-102-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | For stack frames requiring realignment, three pointers may be needed: - ebp to address incoming arguments - esi (could be any callee-saved register) to address locals - esp to address outgoing arguments We would use esi unconditionally without verifying that it did not conflict with inline assembly. This change doesn't do the verification, it simply emits a fatal error on functions that use stack realignment, dynamic SP adjustments, and inline assembly. Because stack realignment is common on Windows, we also no longer assume that MS inline assembly clobbers esp. Instead, we analyze the inline instructions for implicit definitions and check if esp is there. If so, we require the use of a base pointer and consider it in the condition above. Mostly fixes PR16830, but we could try harder to find a non-conflicting base pointer. Reviewers: sunfish Differential Revision: http://llvm-reviews.chandlerc.com/D1317 llvm-svn: 196876
* Fix PR18162 - Incorrect assertion assumed that the SDValue resno is zero.Nadav Rotem2013-12-101-1/+1
| | | | llvm-svn: 196858
* Disable emitting DW_AT_GNU_ranges_base until we actually use it.Eric Christopher2013-12-101-6/+1
| | | | llvm-svn: 196851
* We never emit info into the macro info section, stop emitting anEric Christopher2013-12-102-15/+0
| | | | | | empty one. llvm-svn: 196849
* 80-col.Eric Christopher2013-12-101-1/+2
| | | | llvm-svn: 196848
* Rename CompileUnit->DwarfCompileUnit and TypeUnit->DwarfTypeUnit forEric Christopher2013-12-094-93/+104
| | | | | | clarity. No functional change. llvm-svn: 196844
* Rename Unit->DwarfUnit to match the file name and make it a bit lessEric Christopher2013-12-094-203/+211
| | | | | | ambiguous. Reformat to match. llvm-svn: 196838
* DwarfDebug/Unit: Remove another case of label recreation by storing the ↵David Blaikie2013-12-092-6/+14
| | | | | | gnu_ranges label in the unit. llvm-svn: 196793
OpenPOWER on IntegriCloud