summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* Fix wrong setcc result type when legalizing uaddo/usuboMatt Arsenault2014-05-281-5/+11
| | | | | | | | | No test because no in-tree targets change the bitwidth of the setcc type depending on the bitwidth of the compared type. Patch by Ke Bai llvm-svn: 209771
* test check-in: added missing parenthesis in commentSanjay Patel2014-05-281-1/+1
| | | | llvm-svn: 209763
* Revert "InstCombine: Improvement to check if signed addition overflows."Rafael Espindola2014-05-281-44/+6
| | | | | | | | | This reverts commit r209746. It looks it is causing a crash while building libcxx. I am trying to get a reduced testcase. llvm-svn: 209762
* [pr19844] Add thread local mode to aliases.Rafael Espindola2014-05-2811-64/+60
| | | | | | | | | | This matches gcc's behavior. It also seems natural given that aliases contain other properties that govern how it is accessed (linkage, visibility, dll storage). Clang still has to be updated to expose this feature to C. llvm-svn: 209759
* Add support for combining GEPs across PHI nodesLouis Gerbarg2014-05-281-0/+79
| | | | | | | | | | | | | | | | | | | | | | | | Currently LLVM will generally merge GEPs. This allows backends to use more complex addressing modes. In some cases this is not happening because there is PHI inbetween the two GEPs: GEP1--\ |-->PHI1-->GEP3 GEP2--/ This patch checks to see if GEP1 and GEP2 are similiar enough that they can be cloned (GEP12) in GEP3's BB, allowing GEP->GEP merging (GEP123): GEP1--\ --\ --\ |-->PHI1-->GEP3 ==> |-->PHI2->GEP12->GEP3 == > |-->PHI2->GEP123 GEP2--/ --/ --/ This also breaks certain use chains that are preventing GEP->GEP merges that the the existing instcombine would merge otherwise. Tests included. llvm-svn: 209755
* Revert "[DAGCombiner] Split up an indexed load if only the base pointer ↵Hal Finkel2014-05-281-30/+7
| | | | | | | | | | value is live" This reverts r208640 (I've just XFAILed the test) because it broke ppc64/Linux self-hosting. Because nearly every regression test triggers a segfault, I hope this will be easy to fix. llvm-svn: 209747
* InstCombine: Improvement to check if signed addition overflows.Rafael Espindola2014-05-281-6/+44
| | | | | | | | | | | | | | | | | | This patch implements two things: 1. If we know one number is positive and another is negative, we return true as signed addition of two opposite signed numbers will never overflow. 2. Implemented TODO : If one of the operands only has one non-zero bit, and if the other operand has a known-zero bit in a more significant place than it (not including the sign bit) the ripple may go up to and fill the zero, but won't change the sign. e.x - (x & ~4) + 1 We make sure that we are ignoring 0 at MSB. Patch by Suyog Sarda. llvm-svn: 209746
* Revert "[PPC] Use alias symbols in address computation."Hal Finkel2014-05-282-15/+34
| | | | | | | | | This reverts commit r209638 because it broke self-hosting on ppc64/Linux. (the Clang-compiled TableGen would segfault because it jumped to an invalid address from within _ZNK4llvm17ManagedStaticBase21RegisterManagedStaticEPFPvvEPFvS1_E (which is within the command-line parameter registration process)). llvm-svn: 209745
* [asancov] Don't emit extra runtime calls when compiling without coverage.Evgeniy Stepanov2014-05-281-3/+5
| | | | llvm-svn: 209721
* Change representation of instruction ranges where variable is accessible.Alexey Samsonov2014-05-273-99/+110
| | | | | | | | | | | | | | Use more straightforward way to represent the set of instruction ranges where the location of a user variable is defined - vector of pairs of instructions (defining start/end of each range), instead of a flattened vector of instructions where some instructions are supposed to start the range, and the rest are supposed to "clobber" it. Simplify the code which generates actual .debug_loc entries. No functionality change. llvm-svn: 209698
* Factor out looking for prologue end into a functionAlexey Samsonov2014-05-271-12/+12
| | | | llvm-svn: 209697
* avoid type mismatch when building SCEVsSebastian Pop2014-05-271-0/+26
| | | | | | | | | | | This is a corner case I have stumbled upon when dealing with ARM64 type conversions. I was not able to extract a testcase for the community codebase to fail on. The patch conservatively discards a division that would have ended up in an ICE due to a type mismatch when building a multiply expression. I have also added code to a place that builds add expressions and in which we should be careful not to pass in operands of different types. llvm-svn: 209694
* do not use the GCD to compute the delinearization stridesSebastian Pop2014-05-271-59/+8
| | | | | | | | | | | We do not need to compute the GCD anymore after we removed the constant coefficients from the terms: the terms are now all parametric expressions and there is no need to recognize constant terms that divide only a subset of the terms. We only rely on the size of the terms, i.e., the number of operands in the multiply expressions, to sort the terms and recognize the parametric dimensions. llvm-svn: 209693
* remove BasePointer before delinearizingSebastian Pop2014-05-273-29/+41
| | | | | | | | | | No functional change is intended: instead of relying on the delinearization to come up with the base pointer as a remainder of the divisions in the delinearization, we just compute it from the array access and use that value. We substract the base pointer from the SCEV to be delinearized and that simplifies the work of the delinearizer. llvm-svn: 209692
* remove constant termsSebastian Pop2014-05-273-25/+80
| | | | | | | | | | | | | | | | | | | | | | The delinearization is needed only to remove the non linearity induced by expressions involving multiplications of parameters and induction variables. There is no problem in dealing with constant times parameters, or constant times an induction variable. For this reason, the current patch discards all constant terms and multipliers before running the delinearization algorithm on the terms. The only thing remaining in the term expressions are parameters and multiply expressions of parameters: these simplified term expressions are passed to the array shape recognizer that will not recognize constant dimensions anymore: these will be recognized as different strides in parametric subscripts. The only important special case of a constant dimension is the size of elements. Instead of relying on the delinearization to infer the size of an element, compute the element size from the base address type. This is a much more precise way of computing the element size than before, as we would have mixed together the size of an element with the strides of the innermost dimension. llvm-svn: 209691
* Don't pre-populate the set of keys in the map with variable locations history.Alexey Samsonov2014-05-272-11/+3
| | | | | | | | | | Current implementation of calculateDbgValueHistory already creates the keys in the expected order (user variables are listed in order of appearance), and should do so later by contract. No functionality change. llvm-svn: 209690
* Factor out comparison of Instruction "special" states.Arnaud A. de Grandmaison2014-05-271-84/+55
| | | | | | No functional change. llvm-svn: 209688
* DebugInfo: partially revert cleanup committed in r209680David Blaikie2014-05-271-1/+2
| | | | | | | | | | I'm not sure exactly where/how we end up with an abstract DbgVariable with a null DIE, but we do... looking into it & will add a test and/or fix when I figure it out. Currently shows up in selfhost or compiler-rt builds. llvm-svn: 209683
* DebugInfo: Simplify solution to avoid DW_AT_artificial on inlined parameters.David Blaikie2014-05-273-23/+12
| | | | | | | Originally committed in r207717, I clearly didn't look very closely at the code to understand how existing things were working... llvm-svn: 209680
* [mips] Optimize long branch for MIPS64 by removing %higher and %highest.Sasa Stankovic2014-05-275-42/+29
| | | | | | | | | | %higher and %highest can have non-zero values only for offsets greater than 2GB, which is highly unlikely, if not impossible when compiling a single function. This makes long branch for MIPS64 3 instructions smaller. Differential Revision: http://llvm-reviews.chandlerc.com/D3281.diff llvm-svn: 209678
* DebugInfo: Create abstract function definitions even when concrete ↵David Blaikie2014-05-272-49/+35
| | | | | | | | | | | | | | | definitions preceed inline definitions. After much puppetry, here's the major piece of the work to ensure that even when a concrete definition preceeds all inline definitions, an abstract definition is still created and referenced from both concrete and inline definitions. Variables are still broken in this case (see comment in dbg-value-inlined-parameter.ll test case) and will be addressed in follow up work. llvm-svn: 209677
* DebugInfo: Avoid an extra map lookup when finding abstract subprogram DIEs.David Blaikie2014-05-271-1/+1
| | | | llvm-svn: 209676
* DebugInfo: Lazily construct subprogram definition DIEs.David Blaikie2014-05-271-10/+22
| | | | | | | | | | | | | | | | A further step to correctly emitting concrete out of line definitions preceeding inlined instances of the same program. To do this, emission of subprograms must be delayed until required since we don't know which (abstract only (if there's no out of line definition), concrete only (if there are no inlined instances), or both) DIEs are required at the start of the module. To reduce the test churn in the following commit that actually fixes the bug, this commit introduces the lazy DIE construction and cleans up test cases that are impacted by the changes in the resulting DIE ordering. llvm-svn: 209675
* DebugInfo: Lazily attach definition attributes to definitions.David Blaikie2014-05-273-1/+30
| | | | | | | | | | | | | | | | | | | | | This is a precursor to fixing inlined debug info where the concrete, out-of-line definition may preceed any inlined usage. To cope with this, the attributes that may appear on the concrete definition or the abstract definition are delayed until the end of the module. Then, if an abstract definition was created, it is referenced (and no other attributes are added to the out-of-line definition), otherwise the attributes are added directly to the out-of-line definition. In a couple of cases this causes not just reordering of attributes, but reordering of types. When the creation of the attribute is delayed, if that creation would create a type (such as for a DW_AT_type attribute) then other top level DIEs may've been constructed during the delay, causing the referenced type to be created and added after those intervening DIEs. In the extreme case, in cross-cu-inlining.ll, this actually causes the DW_TAG_basic_type for "int" to move from one CU to another. llvm-svn: 209674
* DebugInfo: Separate out the addition of subprogram attribute additions so ↵David Blaikie2014-05-272-9/+17
| | | | | | that they can be added later depending on whether or not the function is inlined. llvm-svn: 209673
* Distribute sext/zext to the operands of and/or/xorJingyue Wu2014-05-271-13/+29
| | | | | | | | | | | | This is an enhancement to SeparateConstOffsetFromGEP. With this patch, we can extract a constant offset from "s/zext and/or/xor A, B". Added a new test @ext_or to verify this enhancement. Refactoring the code, I also extracted some common logic to function Distributable. llvm-svn: 209670
* Post-commit fixes for r209643Filipe Cabecinhas2014-05-271-3/+7
| | | | | | | | | | Detected by Daniel Jasper, Ilia Filippov, and Andrea Di Biagio Fixed the argument order to select (the mask semantics to blendv* are the inverse of select) and fixed the tests Added parenthesis to the assert condition Ran clang-format llvm-svn: 209667
* [PATCH] Correct type used for VADD_SPLAT optimization on PowerPCBill Schmidt2014-05-271-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In PPCISelLowering.cpp: PPCTargetLowering::LowerBUILD_VECTOR(), there is an optimization for certain patterns to generate one or two vector splats followed by a vector add or subtract. This operation is represented by a VADD_SPLAT in the selection DAG. Prior to this patch, it was possible for the VADD_SPLAT to be assigned the wrong data type, causing incorrect code generation. This patch corrects the problem. Specifically, the code previously assigned the value type of the BUILD_VECTOR node to the newly generated VADD_SPLAT node. This is correct much of the time, but not always. The problem is that the call to isConstantSplat() may return a SplatBitSize that is not the same as the number of bits in the original element vector type. The correct type to assign is a vector type with the same element bit size as SplatBitSize. The included test case shows an example of this, where the BUILD_VECTOR node has a type of v16i8. The vector to be built is {0, 16, 0, 16, 0, 16, 0, 16, 0, 16, 0, 16, 0, 16, 0, 16}. isConstantSplat detects that we can generate a splat of 16 for type v8i16, which is the type we must assign to the VADD_SPLAT node. If we do not, we generate a vspltisb of 8 and a vaddubm, which generates the incorrect result {16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16}. The correct code generation is a vspltish of 8 and a vadduhm. This patch also corrected code generation for CodeGen/PowerPC/2008-07-10-SplatMiscompile.ll, which had been marked as an XFAIL, so we can remove the XFAIL from the test case. llvm-svn: 209662
* [mips][mips64r6] Add Relocations R_MIPS_PCHI16, R_MIPS_PCLO16 Zoran Jovanovic2014-05-277-0/+30
| | | | | | Differential Revision: http://reviews.llvm.org/D3860 llvm-svn: 209659
* [ARM] Emit correct build attributes for the relocation models.Amara Emerson2014-05-271-0/+14
| | | | | | Patch by Asiri Rathnayake. llvm-svn: 209656
* [mips][mips64r6] Add relocations R_MIPS_PC21_S2, R_MIPS_PC26_S2 Zoran Jovanovic2014-05-274-2/+38
| | | | | | Differential Revision: http://reviews.llvm.org/D3824 llvm-svn: 209655
* [asancov] Emit an initializer passing number of coverage code locations in ↵Evgeniy Stepanov2014-05-271-4/+14
| | | | | | each module. llvm-svn: 209654
* AArch64: implement copies to/from NZCV as a last ditch effort.Tim Northover2014-05-272-2/+20
| | | | | | | | | | A test in test/Generic creates a DAG where the NZCV output of an ADCS is used by multiple nodes. This makes LLVM want to save a copy of NZCV for later, which it couldn't do before. This should be the last fix required for the aarch64 buildbot. llvm-svn: 209651
* ARM: teach AAPCS-VFP to deal with Cortex-M4.Tim Northover2014-05-273-21/+32
| | | | | | | | | | | Cortex-M4 only has single-precision floating point support, so any LLVM "double" type will have been split into 2 i32s by now. Fortunately, the consecutive-register framework turns out to be precisely what's needed to reconstruct the double and follow AAPCS-VFP correctly! rdar://problem/17012966 llvm-svn: 209650
* Fix bad assert.Daniel Jasper2014-05-271-1/+2
| | | | llvm-svn: 209648
* AArch64: support 'c' and 'n' inline asm modifiers.Tim Northover2014-05-271-0/+5
| | | | | | | These are tested by test/CodeGen/Generic, so we should probably know how to deal with them. Fortunately generic code does it if asked. llvm-svn: 209646
* Convert some X86 blendv* intrinsics into IR.Filipe Cabecinhas2014-05-271-0/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Implemented an InstCombine transformation that takes a blendv* intrinsic call and translates it into an IR select, if the mask is constant. This will eventually get lowered into blends with immediates if possible, or pblendvb (with an option to further optimize if we can transform the pblendvb into a blend+immediate instruction, depending on the selector). It will also enable optimizations by the IR passes, which give up on sight of the intrinsic. Both the transformation and the lowering of its result to asm got shiny new tests. The transformation is a bit convoluted because of blendvp[sd]'s definition: Its mask is a floating point value! This forces us to convert it and get the highest bit. I suppose this happened because the mask has type __m128 in Intel's intrinsic and v4sf (for blendps) in gcc's builtin. I will send an email to llvm-dev to discuss if we want to change this or not. Reviewers: grosbach, delena, nadav Differential Revision: http://reviews.llvm.org/D3859 llvm-svn: 209643
* Use existing helper function.Rafael Espindola2014-05-261-8/+1
| | | | | | No functionality change. llvm-svn: 209639
* [PPC] Use alias symbols in address computation.Rafael Espindola2014-05-262-34/+15
| | | | | | | This seems to match what gcc does for ppc and what every other llvm backend does. llvm-svn: 209638
* AArch64: force i1 to be zero-extended at an ABI boundary.Tim Northover2014-05-261-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit is debatable. There are two possible approaches, neither of which is really satisfactory: 1. Use "@foo(i1 zeroext)" to mean an extension to 32-bits on Darwin, and 8 bits otherwise. 2. Redefine "@foo(i1)" to mean that the i1 is extended by the caller to 8 bits. This goes against the spirit of "zeroext" I think, but it's a bit of a vague construct anyway (by definition you're going to extend to the amount required by the ABI, that's why it's the ABI!). This implements option 2. The DAG machinery really isn't setup for the first (there's a fairly strong assumption that "zeroext" goes to at least the smallest register size), and even if it was the resulting DAG looks like it would be inferior in many cases. Theoretically we could add AssertZext nodes in the consumers of ABI-passed values too now, but this actually seems to make the code worse in practice by making truncation proceed in two steps. The code produced is equally valid if we continue to assume only the low bit is defined. Should fix PR19850 llvm-svn: 209637
* AArch64: simplify calling conventions slightly.Tim Northover2014-05-264-128/+36
| | | | | | | | | We can eliminate the custom C++ code in favour of some TableGen to check the same things. Functionality should be identical, except for a buffer overrun that was present in the C++ code and meant webkit failed if any small argument needed to be passed on the stack. llvm-svn: 209636
* Some cleanup for r209568.Michael Zolotukhin2014-05-261-9/+7
| | | | llvm-svn: 209634
* Convert a few loops to use ranges.Rafael Espindola2014-05-261-54/+51
| | | | llvm-svn: 209628
* [asan] decrease asan-instrumentation-with-call-threshold from 10000 to 7000, ↵Kostya Serebryany2014-05-261-1/+1
| | | | | | see PR17409 llvm-svn: 209623
* Make the LoopRotate pass's maximum header size configurable both ↵Owen Anderson2014-05-261-4/+14
| | | | | | | | | | programmatically and via the command line, mirroring similar functionality in LoopUnroll. In situations where clients used custom unrolling thresholds, their intent could previously be foiled by LoopRotate having a hardcoded threshold. llvm-svn: 209617
* DwarfUnit: Remove some misleading no-op code introduced in r204162.David Blaikie2014-05-261-4/+0
| | | | | | | Post commit review feedback from Manman called this out, but it looks like it slipped through the cracks. llvm-svn: 209611
* DebugInfo: Fix inlining with #file directives a little harderDavid Blaikie2014-05-251-5/+5
| | | | | | | | | | | Seems my previous fix was insufficient - we were still not adding the inlined function to the abstract scope list. Which meant it wasn't flagged as inline, didn't have nested lexical scopes in the abstract definition, and didn't have abstract variables - so the inlined variable didn't reference an abstract variable, instead being described completely inline. llvm-svn: 209602
* Emit data or code export directives based on the type.Rafael Espindola2014-05-251-7/+3
| | | | | | | | | | | | | | | | | | | | | | Currently we look at the Aliasee to decide what type of export directive to use. It seems better to use the type of the alias directly. This is similar to how we handle the alias having the same address but other attributes (linkage, visibility) from the aliasee. With this patch it is now possible to do things like target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-pc-windows-msvc" @foo = global [6 x i8] c"\B8*\00\00\00\C3", section ".text", align 16 @f = dllexport alias i32 (), [6 x i8]* @foo !llvm.module.flags = !{!0} !0 = metadata !{i32 6, metadata !"Linker Options", metadata !1} !1 = metadata !{metadata !2, metadata !3} !2 = metadata !{metadata !"/DEFAULTLIB:libcmt.lib"} !3 = metadata !{metadata !"/DEFAULTLIB:oldnames.lib"} llvm-svn: 209600
* Add an extension point for peephole optimizers.Peter Collingbourne2014-05-251-0/+9
| | | | | | | | | | This extension point allows adding passes that perform peephole optimizations similar to the instruction combiner. These passes will be inserted after each instance of the instruction combiner pass. Differential Revision: http://reviews.llvm.org/D3905 llvm-svn: 209595
* Fix some misplaced spaces around 'override'Hans Wennborg2014-05-242-2/+2
| | | | llvm-svn: 209589
OpenPOWER on IntegriCloud