summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix an infinite loop bug in DAG Combine about keeping transfering between ↵Hao Liu2014-04-221-9/+7
| | | | | | ANY_EXTEND and SIGN_EXTEND. llvm-svn: 206873
* Revert "Use value semantics to manage DbgVariables rather than dynamic ↵David Blaikie2014-04-222-57/+54
| | | | | | | | | | | allocation/pointers." This reverts commit r206780. This commit was regressing gdb.opt/inline-locals.exp in the GDB 7.5 test suite. Reverting until I can fix the issue. llvm-svn: 206867
* [Modules] Remove potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-2288-97/+176
| | | | | | | | | | | | define below all header includes in the lib/CodeGen/... tree. While the current modules implementation doesn't check for this kind of ODR violation yet, it is likely to grow support for it in the future. It also removes one layer of macro pollution across all the included headers. Other sub-trees will follow. llvm-svn: 206837
* [CodeGenPrepare] Use APInt to check the value of the immediate in a andQuentin Colombet2014-04-221-2/+2
| | | | | | | | | | while checking candidate for bit field extract. Otherwise the value may not fit in uint64_t and this will trigger an assertion. This fixes PR19503. llvm-svn: 206834
* [Modules] Make Support/Debug.h modular. This requires it to not changeChandler Carruth2014-04-214-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Set default value of HasExtractBitsInsn to falseYi Jiang2014-04-211-0/+1
| | | | llvm-svn: 206803
* Remove seemingly-unneeded artificial dependencyHal Finkel2014-04-211-5/+0
| | | | | | | | | | | | | | | | The rationale for this artificial dependency seems to have been lost to the ravages of time, it is covered by no regression tests, and has no impact on test-suite performance numbers on either x86 or PPC. For the test suite, on both x86 and PPC, I ran the test suite 10 times (both as a baseline and with this change), and found no statistically-significant changes. For PPC, I used a P7 box. For x86, I used an Intel Xeon E5430. Both with -O3 -mcpu=native. This was discussed on-list back in January, but I've not had a chance to run the performance tests until today. llvm-svn: 206795
* Use unique_ptr to handle ownership of UserValues in LiveDebugVariablesImplDavid Blaikie2014-04-211-4/+6
| | | | llvm-svn: 206785
* Use unique_ptr to manage objects owned by the ScheduleDAGMI.David Blaikie2014-04-211-10/+9
| | | | llvm-svn: 206784
* Use value semantics to manage DbgVariables rather than dynamic ↵David Blaikie2014-04-212-54/+57
| | | | | | | | | | allocation/pointers. Requires switching some vectors to lists to maintain pointer validity. These could be changed to forward_lists (singly linked) with a bit more work - I've left comments to that effect. llvm-svn: 206780
* [Modules] Sink the DEBUG_TYPE macro out of LegalizeTypes.h and into theChandler Carruth2014-04-216-1/+5
| | | | | | | various .cpp files. This macro is inherently non-modular, and it wasn't even needed in this header file. llvm-svn: 206775
* ARM64: Combine shifts and uses from different basic block to bit-extract ↵Yi Jiang2014-04-211-0/+192
| | | | | | instruction llvm-svn: 206774
* Fix unnecessary line breakMatt Arsenault2014-04-211-4/+2
| | | | llvm-svn: 206772
* Reapply "blockfreq: Rewrite BlockFrequencyInfoImpl"Duncan P. N. Exon Smith2014-04-211-3/+9
| | | | | | | | | This reverts commit r206707, reapplying r206704. The preceding commit to CalcSpillWeights should have sorted out the failing buildbots. <rdar://problem/14292693> llvm-svn: 206766
* CalcSpillWeights: Hack to prevent x87 nonsenseDuncan P. N. Exon Smith2014-04-211-1/+5
| | | | | | | | | This gross hack forces `hweight` into memory, preventing hidden precision from making `1 > 1` occasionally equal `true`. <rdar://problem/14292693> llvm-svn: 206765
* Reapply r206732. This time without optimization of branches.Michael Zolotukhin2014-04-212-0/+237
| | | | llvm-svn: 206749
* Revert r206732 which is causing llc to crash on most of the build bots.Chandler Carruth2014-04-212-288/+0
| | | | | | | | Original commit message: Implement builtins for safe division: safe.sdiv.iN, safe.udiv.iN, safe.srem.iN, safe.urem.iN (iN = i8, i61, i32, or i64). llvm-svn: 206735
* Implement builtins for safe division: safe.sdiv.iN, safe.udiv.iN, safe.srem.iN,Michael Zolotukhin2014-04-212-0/+288
| | | | | | safe.urem.iN (iN = i8, i16, i32, or i64). llvm-svn: 206732
* Revert "blockfreq: Rewrite BlockFrequencyInfoImpl"Duncan P. N. Exon Smith2014-04-191-9/+3
| | | | | | This reverts commit r206704, as expected. llvm-svn: 206707
* Reapply "blockfreq: Rewrite BlockFrequencyInfoImpl"Duncan P. N. Exon Smith2014-04-191-3/+9
| | | | | | | | | | | | | | | | | | | | | This reverts commit r206677, reapplying my BlockFrequencyInfo rewrite. I've done a careful audit, added some asserts, and fixed a couple of bugs (unfortunately, they were in unlikely code paths). There's a small chance that this will appease the failing bots [1][2]. (If so, great!) If not, I have a follow-up commit ready that will temporarily add -debug-only=block-freq to the two failing tests, allowing me to compare the code path between what the failing bots and what my machines (and the rest of the bots) are doing. Once I've triggered those builds, I'll revert both commits so the bots go green again. [1]: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/1816 [2]: http://llvm-amd64.freebsd.your.org/b/builders/clang-i386-freebsd/builds/18445 <rdar://problem/14292693> llvm-svn: 206704
* Patch by Vadim ChugunovYaron Keren2014-04-193-3/+10
| | | | | | | | | | | Win64 stack unwinder gets confused when execution flow "falls through" after a call to 'noreturn' function. This fixes the "missing epilogue" problem by emitting a trap instruction for IR 'unreachable' on x86_x64-pc-windows. A secondary use for it would be for anyone wanting to make double-sure that 'noreturn' functions, indeed, do not return. llvm-svn: 206684
* Revert "blockfreq: Rewrite BlockFrequencyInfoImpl" (#2)Duncan P. N. Exon Smith2014-04-191-9/+3
| | | | | | | | | | | This reverts commit r206666, as planned. Still stumped on why the bots are failing. Sanitizer bots haven't turned anything up. If anyone can help me debug either of the failures (referenced in r206666) I'll owe them a beer. (In the meantime, I'll be auditing my patch for undefined behaviour.) llvm-svn: 206677
* Reapply "blockfreq: Rewrite BlockFrequencyInfoImpl" (#2)Duncan P. N. Exon Smith2014-04-181-3/+9
| | | | | | | | | | | | | | | | | | | This reverts commit r206628, reapplying r206622 (and r206626). Two tests are failing only on buildbots [1][2]: i.e., I can't reproduce on Darwin, and Chandler can't reproduce on Linux. Asan and valgrind don't tell us anything, but we're hoping the msan bot will catch it. So, I'm applying this again to get more feedback from the bots. I'll leave it in long enough to trigger builds in at least the sanitizer buildbots (it was failing for reasons unrelated to my commit last time it was in), and hopefully a few others.... and then I expect to revert a third time. [1]: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/1816 [2]: http://llvm-amd64.freebsd.your.org/b/builders/clang-i386-freebsd/builds/18445 llvm-svn: 206666
* Revert "blockfreq: Rewrite BlockFrequencyInfoImpl" (#2)Duncan P. N. Exon Smith2014-04-181-9/+3
| | | | | | | | | This reverts commit r206622 and the MSVC fixup in r206626. Apparently the remotely failing tests are still failing, despite my attempt to fix the nondeterminism in r206621. llvm-svn: 206628
* Better comments to explain buffered/unbuffered processor resources.Andrew Trick2014-04-181-4/+8
| | | | llvm-svn: 206625
* Reapply "blockfreq: Rewrite BlockFrequencyInfoImpl"Duncan P. N. Exon Smith2014-04-181-3/+9
| | | | | | | | | | | | | | This reverts commit r206556, effectively reapplying commit r206548 and its fixups in r206549 and r206550. In an intervening commit I've added target triples to the tests that were failing remotely [1] (but passing locally). I'm hoping the mystery is solved? I'll revert this again if the tests are still failing remotely. [1]: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/1816 llvm-svn: 206622
* Revert "blockfreq: Rewrite BlockFrequencyInfoImpl"Duncan P. N. Exon Smith2014-04-181-9/+3
| | | | | | | | | | | This reverts commits r206548, r206549 and r206549. There are some unit tests failing that aren't failing locally [1], so reverting until I have time to investigate. [1]: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/1816 llvm-svn: 206556
* blockfreq: Rewrite BlockFrequencyInfoImplDuncan P. N. Exon Smith2014-04-181-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rewrite the shared implementation of BlockFrequencyInfo and MachineBlockFrequencyInfo entirely. The old implementation had a fundamental flaw: precision losses from nested loops (or very wide branches) compounded past loop exits (and convergence points). The @nested_loops testcase at the end of test/Analysis/BlockFrequencyAnalysis/basic.ll is motivating. This function has three nested loops, with branch weights in the loop headers of 1:4000 (exit:continue). The old analysis gives non-sensical results: Printing analysis 'Block Frequency Analysis' for function 'nested_loops': ---- Block Freqs ---- entry = 1.0 for.cond1.preheader = 1.00103 for.cond4.preheader = 5.5222 for.body6 = 18095.19995 for.inc8 = 4.52264 for.inc11 = 0.00109 for.end13 = 0.0 The new analysis gives correct results: Printing analysis 'Block Frequency Analysis' for function 'nested_loops': block-frequency-info: nested_loops - entry: float = 1.0, int = 8 - for.cond1.preheader: float = 4001.0, int = 32007 - for.cond4.preheader: float = 16008001.0, int = 128064007 - for.body6: float = 64048012001.0, int = 512384096007 - for.inc8: float = 16008001.0, int = 128064007 - for.inc11: float = 4001.0, int = 32007 - for.end13: float = 1.0, int = 8 Most importantly, the frequency leaving each loop matches the frequency entering it. The new algorithm leverages BlockMass and PositiveFloat to maintain precision, separates "probability mass distribution" from "loop scaling", and uses dithering to eliminate probability mass loss. I have unit tests for these types out of tree, but it was decided in the review to make the classes private to BlockFrequencyInfoImpl, and try to shrink them (or remove them entirely) in follow-up commits. The new algorithm should generally have a complexity advantage over the old. The previous algorithm was quadratic in the worst case. The new algorithm is still worst-case quadratic in the presence of irreducible control flow, but it's linear without it. The key difference between the old algorithm and the new is that control flow within a loop is evaluated separately from control flow outside, limiting propagation of precision problems and allowing loop scale to be calculated independently of mass distribution. Loops are visited bottom-up, their loop scales are calculated, and they are replaced by pseudo-nodes. Mass is then distributed through the function, which is now a DAG. Finally, loops are revisited top-down to multiply through the loop scales and the masses distributed to pseudo nodes. There are some remaining flaws. - Irreducible control flow isn't modelled correctly. LoopInfo and MachineLoopInfo ignore irreducible edges, so this algorithm will fail to scale accordingly. There's a note in the class documentation about how to get closer. See also the comments in test/Analysis/BlockFrequencyInfo/irreducible.ll. - Loop scale is limited to 4096 per loop (2^12) to avoid exhausting the 64-bit integer precision used downstream. - The "bias" calculation proposed on llvmdev is *not* incorporated here. This will be added in a follow-up commit, once comments from this review have been handled. llvm-svn: 206548
* Fix bug 19437 - Only add discriminators for DWARF 4 and above.Diego Novillo2014-04-171-9/+1
| | | | | | | | | | | | | | Summary: This prevents the discriminator generation pass from triggering if the DWARF version being used in the module is prior to 4. Reviewers: echristo, dblaikie CC: llvm-commits Differential Revision: http://reviews.llvm.org/D3413 llvm-svn: 206507
* [stack protector] Make the StackProtector pass respect ssp-buffer-size.Josh Magee2014-04-171-3/+3
| | | | | | | | | | | Previously, SSPBufferSize was assigned the value of the "stack-protector-buffer-size" attribute after all uses of SSPBufferSize. The effect was that the default SSPBufferSize was always used during analysis. I moved the check for the attribute before the analysis; now --param ssp-buffer-size= works correctly again. Differential Revision: http://reviews.llvm.org/D3349 llvm-svn: 206486
* Atomics: promote ARM's IR-based atomics pass to CodeGen.Tim Northover2014-04-173-0/+338
| | | | | | | | | | | | Still only 32-bit ARM using it at this stage, but the promotion allows direct testing via opt and is a reasonably self-contained patch on the way to switching ARM64. At this point, other targets should be able to make use of it without too much difficulty if they want. (See ARM64 commit coming soon for an example). llvm-svn: 206485
* [c++11] Tidy up AsmPrinter.cpp.Jim Grosbach2014-04-161-95/+77
| | | | | | | Range'ify loops and tidy up some by-reference handling. No functional change. llvm-svn: 206422
* DAGCombiner: don't optimise non-existant litpool loadTim Northover2014-04-161-1/+3
| | | | | | | | | | | This particular DAG combine is designed to kick in when both ConstantFPs will end up being loaded via a litpool, however those nodes have a semi-legal status, dictated by isFPImmLegal so in some cases there wouldn't have been a litpool in the first place. Don't try to be clever in those circumstances. Picked up while merging some AArch64 tests. llvm-svn: 206365
* Convert SelectionDAG::getVTList to use ArrayRefCraig Topper2014-04-165-18/+19
| | | | llvm-svn: 206357
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-169-32/+37
| | | | | | instead of comparing to nullptr. llvm-svn: 206356
* Make FastISel::SelectInstruction return before target specific fast-isel codeAkira Hatanaka2014-04-151-2/+8
| | | | | | | | | | | handles Intrinsic::trap if TargetOptions::TrapFuncName is set. This fixes a bug in which the trap function was not taken into consideration when a program was compiled without optimization (at -O0). <rdar://problem/16291933> llvm-svn: 206323
* Revert r191049/r191059 as it can produce wrong code (see PR17975).Robert Lougher2014-04-151-21/+0
| | | | | | It has already been reverted on the 3.4 branch in r196521. llvm-svn: 206311
* verify-di: Implement DebugInfoVerifierDuncan P. N. Exon Smith2014-04-151-1/+9
| | | | | | | | | | | | | | | | | | | | | Implement DebugInfoVerifier, which steals verification relying on DebugInfoFinder from Verifier. - Adds LegacyDebugInfoVerifierPassPass, a ModulePass which wraps DebugInfoVerifier. Uses -verify-di command-line flag. - Change verifyModule() to invoke DebugInfoVerifier as well as Verifier. - Add a call to createDebugInfoVerifierPass() wherever there was a call to createVerifierPass(). This implementation as a module pass should sidestep efficiency issues, allowing us to turn debug info verification back on. <rdar://problem/15500563> llvm-svn: 206300
* FastISel: constrain the RegClass of operands when emitting instructions.Tim Northover2014-04-151-8/+47
| | | | | | | | | | | ARM64 suffered multiple -verify-machineinstr failures (principally over the xsp/xzr issue) because FastISel was completely ignoring which subset of the general-purpose registers each instruction required. More fixes are coming in ARM64 specific FastISel, but this should cover the generic problems. llvm-svn: 206283
* Break PseudoSourceValue out of the Value hierarchy. It is now the root of ↵Nick Lewycky2014-04-1511-231/+143
| | | | | | 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
* Use unique_ptr to manage TypePromotionActions owned by TypePromotionTransaction.David Blaikie2014-04-151-28/+19
| | | | llvm-svn: 206250
* Use unique_ptr to manage ownership of GCFunctionInfos in GCStrategyDavid Blaikie2014-04-151-10/+2
| | | | llvm-svn: 206249
* Use unique_ptr for the result of Registry entries.David Blaikie2014-04-152-8/+6
| | | | llvm-svn: 206248
* Use unique_ptr to manage ownership of GCStrategy objects in GCMetadataDavid Blaikie2014-04-152-19/+12
| | | | llvm-svn: 206246
* Use std::unique_ptr for DIE childrenDavid Blaikie2014-04-145-43/+31
| | | | | | | | | Got bored, removed some manual memory management. Pushed references (rather than pointers) through a few APIs rather than replacing *x with x.get(). llvm-svn: 206222
* Re-apply r206096 after investigating the gdb buildbot failure.Adrian Prantl2014-04-141-9/+14
| | | | | | | | | | | | | | | Thanks to dblaikie for updating the testcase! Debug info: (bugfix) C++ C/Dtors can be compiled to multiple functions, therefore, their declaration cannot have one DW_AT_linkage_name. The specific instances however can and should have that attribute. This patch reorders the code in DwarfUnit::getOrCreateSubprogramDIE() to emit linkage names for C/Dtors. rdar://problem/16362674. llvm-svn: 206210
* Don't assert in BasicTTI::getMemoryOpCost for non-simple typesHal Finkel2014-04-141-6/+8
| | | | | | | | BasicTTI::getMemoryOpCost must explicitly check for non-simple types; setting AllowUnknown=true with TLI->getSimpleValueType is not sufficient because, for example, non-power-of-two vector types return non-simple EVTs (not MVT::Other). llvm-svn: 206150
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-1493-1017/+1025
| | | | | | instead of comparing to nullptr. llvm-svn: 206142
* Retire llvm::array_endof in favor of non-member std::end.Benjamin Kramer2014-04-121-1/+1
| | | | | | While there make array_lengthof constexpr if we have support for it. llvm-svn: 206112
* PR13337: Omit DW_TAG_restrict_type when compiling for DWARF2David Blaikie2014-04-121-0/+4
| | | | | | | DWARF3 introduced DW_TAG_restrict_type, so avoid using it in prior versions. llvm-svn: 206105
OpenPOWER on IntegriCloud