summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* Do not assert when trying to replace the log with another logAndreas Simbuerger2014-08-141-3/+3
| | | | | | | This usually happens when TempScopInfo calls isMaxRegionInScop(..), so don't fail there. llvm-svn: 215624
* Revert to heuristical DebugLoc findingAndreas Simbuerger2014-08-141-8/+32
| | | | llvm-svn: 215623
* [SDAG] Fix a bug in the DAG combiner where we would fail to return theChandler Carruth2014-08-142-5/+25
| | | | | | | | | | | | | | | | | | | | | | | input node after manually adding it to the worklist and using CombineTo. Once we use CombineTo the input node may have been deleted. Despite this being *completely confusing* and somewhat broken, the only way to "correctly" return from a DAG combine after potentially deleting the input node is to return *that exact node*.... But really, this code should just never have used CombineTo. It won't do what it wants (returning the node as mentioned above just causes the combine to infloop). The correct way to combine away a casted load to a load of the correct type is to RAUW the chain directly and then return the loaded value to replace the actual value node. I managed to find this with the vector shuffle fuzzer even though it clearly has nothing at all to do with vector shuffles and rather those happen to trigger a load of a constant pool that hits this combine *just right*. I've included the test as it is small and a nice stress test that the infrastructure isn't asserting. llvm-svn: 215622
* InstCombine: ((A | ~B) ^ (~A | B)) to A ^ BDavid Majnemer2014-08-142-0/+23
| | | | | | | | | | | | | | | Proof using CVC3 follows: $ cat t.cvc A, B : BITVECTOR(32); QUERY BVXOR((A | ~B),(~A |B)) = BVXOR(A,B); $ cvc3 t.cvc Valid. Patch by Mayur Pandey! Differential Revision: http://reviews.llvm.org/D4883 llvm-svn: 215621
* AArch64: Silence warning in AArch64FastISelDavid Majnemer2014-08-141-1/+1
| | | | | | GCC was emitting a signed vs unsigned comparison warning. llvm-svn: 215620
* Added InstCombine Transform for ((B | C) & A) | B -> B | (A & C)David Majnemer2014-08-142-0/+15
| | | | | | | | | | | | Transform ((B | C) & A) | B --> B | (A & C) Z3 Link: http://rise4fun.com/Z3/hP6p Patch by Sonam Kumari! Differential Revision: http://reviews.llvm.org/D4865 llvm-svn: 215619
* Parse: Don't attempt to act on #pragma init_seg when not targeting MSVCDavid Majnemer2014-08-143-1/+18
| | | | | | | | | | It doesn't really make sense to try and do stuff with #pragma init_seg when targeting non-Microsoft platforms; notions like library vs user initializers don't exist for other targets. This fixes PR20639. llvm-svn: 215618
* [modules] Factor .td-generated diagnostics stuff out into its own module; thisRichard Smith2014-08-141-6/+18
| | | | | | | avoids users of AllDiagnostics.h from needing to pregenerate *all* generated headers. Hopefully this will make my modules buildbot happier... llvm-svn: 215617
* [modules] Don't assert if the same imported class template specializationRichard Smith2014-08-144-2/+19
| | | | | | | declaration has its definition instantiated in two sibling modules and they use a partial specialization. llvm-svn: 215616
* MC: AsmLexer: handle multi-character CommentStrings correctlySaleem Abdulrasool2014-08-144-6/+34
| | | | | | | | | | | | As X86MCAsmInfoDarwin uses '##' as CommentString although a single '#' starts a comment a workaround for this special case is added. Fixes divisions in constant expressions for the AArch64 assembler and other targets which use '//' as CommentString. Patch by Janne Grunau! llvm-svn: 215615
* CodeGen: When bitfields fall on natural boundaries, split them upJustin Bogner2014-08-142-2/+88
| | | | | | | | | | | | | | | | | | | Currently when laying out bitfields that don't need any padding, we represent them as a wide enough int to contain all of the bits. This can be hard on the backend since we'll do things like represent stores to a few bits as loading an i144, masking it with a large constant, and storing it back. This turns up in less pathological cases where we load and mask 64 bit word on a 32 bit platform when we actually only need to access 32 bits. This leads to bad code being generated in most of our 32 bit backends. In practice, there are often natural breaks in bitfields, and it's a fairly simple and effective heuristic to split these fields into legal integer sized chunks when it will be equivalent (ie, it won't force us to add any extra padding). llvm-svn: 215614
* [MCJIT] Support DisableSymbolSearching and InstallLazyFunctionCreator in MCJIT.Lang Hames2014-08-141-5/+13
| | | | | | Patch by Anthony Pesch. Thanks Anthony! llvm-svn: 215613
* [modules] When we merge together multiple class template specializationRichard Smith2014-08-146-28/+69
| | | | | | | | | | definitions (because some other declaration declares a special member that isn't present in the canonical definition), we need to search *all* of them; we can't just stop when we find the requested name in any of the definitions, because that can fail to find things (and in particular, it can fail to find the member of the canonical declaration and return a bogus ODR failure). llvm-svn: 215612
* [SDAG] Fix a case where we would iteratively legalize a node duringChandler Carruth2014-08-142-0/+22
| | | | | | | | | | | | | | | | | | combining by replacing it with something else but not re-process the node afterward to remove it. In a truly remarkable stroke of bad luck, this would (in the test case attached) end up getting some other node combined into it without ever getting re-processed. By adding it back on to the worklist, in addition to deleting the dead nodes more quickly we also ensure that if it *stops* being dead for any reason it makes it back through the legalizer. Without this, the test case will end up failing during instruction selection due to an and node with a type we don't have an instruction pattern for. It took many million runs of the shuffle fuzz tester to find this. llvm-svn: 215611
* Remove llvm_headers_do_not_build for the benefit of XCode and Visual Studio ↵Michael J. Spencer2014-08-141-13/+0
| | | | | | users. llvm-svn: 215610
* Sema: Permit nullptr template args in MSVC compat modeDavid Majnemer2014-08-142-2/+6
| | | | | | This fixes a regression I caused back in r211766. llvm-svn: 215609
* Don't enable STDIN for cases where we are supplying lines to be run in the ↵Greg Clayton2014-08-141-2/+2
| | | | | | | | embedded python interpreter. <rdar://problem/17949057> llvm-svn: 215608
* clang/test/Modules/cxx-irgen.cpp: Let it tolerant of x86_thiscallcc.NAKAMURA Takumi2014-08-141-4/+4
| | | | llvm-svn: 215607
* Simplify some CodeGenTypes::arrangeXXX functions. No functionality changeAlexey Samsonov2014-08-131-28/+10
| | | | llvm-svn: 215606
* [mach-o] Support re-exported dylibsNick Kledzik2014-08-1311-57/+351
| | | | | | | | | | | | | | | | | | | | In general two-level namespace means each program records exactly which dylib each undefined (imported) symbol comes from. But, sometimes the implementor wants to hide the implementation dylib. For instance libSytem.dylib is the base dylib all Darwin programs must link with. A few years ago it was split up into two dozen dylibs by all are hidden behind libSystem.dylib which re-exports each sub-dylib. All clients still think libSystem.dylib is the implementor. To support this, the linker must load "indirect" dylibs and not just the "direct" dylibs specified on the command line. This is done in the createImplicitFiles() method after all command line specified files are loaded. Since an indirect dylib may have already been loaded as a direct dylib (or indirectly via a previous direct dylib), the MachOLinkingContext keeps a list of all loaded dylibs. With this change hello world can now be linked against the real OS or SDK. llvm-svn: 215605
* [X86] Fix the value of the low mask for the lowering of MUL_LOHI for v4i32.Quentin Colombet2014-08-131-1/+1
| | | | | | Found by code inspection. llvm-svn: 215604
* Objective-C. Handle case of multiple class methodsFariborz Jahanian2014-08-132-2/+13
| | | | | | found in global pool as well. rdar://16808765 llvm-svn: 215603
* [mach-o] Fix stub generation to work for dylibs and bundlesNick Kledzik2014-08-137-26/+59
| | | | | | | | | | Split up the CRuntimeFile into one part for output types that need an entry point and another part for output types that use stubs. Add file 'test/mach-o/Inputs/libSystem.yaml' for use by test cases that use -dylib and therefore may now need the helper symbol in libSystem.dylib. llvm-svn: 215602
* Whitespace fix.Rafael Espindola2014-08-131-1/+1
| | | | | | Sorry about the noise. llvm-svn: 215601
* [AArch64, fast-isel] Fall back to SelectionDAG to select tail calls.Akira Hatanaka2014-08-133-1/+19
| | | | | | | | | | Certain functions such as objc_autoreleaseReturnValue have to be called as tail-calls even at -O0. Since normal fast-isel doesn't emit calls as tail calls, we have to fall back to SelectionDAG to select calls that are marked as tail. <rdar://problem/17991614> llvm-svn: 215600
* ARM: Add mappings for ACLE prefetch intrinsicsYi Kong2014-08-133-0/+59
| | | | | | | Implement __pld, __pldx, __pli and __plix builtin intrinsics as specified in ARM ACLE 2.0. llvm-svn: 215599
* [mach-o] set ordinal in n_desc for undefined symbolsNick Kledzik2014-08-135-18/+23
| | | | | | | | | | | Mach-o uses "two-level namespace" where each undefined symbols is associated with a specific dylib. This means at runtime the loader (dyld) does need to search all loaded dylibs for that symbol but rather just the one specified. Now that llvm-nm -m prints out that info, properly set that info, and test it in the hello world test cases. llvm-svn: 215598
* [FastISel][AArch64] Add support for more addressing modes.Juergen Ributzka2014-08-132-168/+714
| | | | | | | | | | | | | | | | | FastISel didn't take much advantage of the different addressing modes available to it on AArch64. This commit allows the ComputeAddress method to recognize more addressing modes that allows shifts and sign-/zero-extensions to be folded into the memory operation itself. For Example: lsl x1, x1, #3 --> ldr x0, [x0, x1, lsl #3] ldr x0, [x0, x1] sxtw x1, w1 lsl x1, x1, #3 --> ldr x0, [x0, x1, sxtw #3] ldr x0, [x0, x1] llvm-svn: 215597
* <rdar://problem/18001677>Han Ming Ong2014-08-131-20/+14
| | | | | | Use the right mechanism to put the XPC services now that Xcode supports the workflow. llvm-svn: 215596
* [FastISel][X86] Add large code model support for materializing ↵Juergen Ributzka2014-08-132-17/+37
| | | | | | | | | | | | | | floating-point constants. In the large code model for X86 floating-point constants are placed in the constant pool and materialized by loading from it. Since the constant pool could be far away, a PC relative load might not work. Therefore we first materialize the address of the constant pool with a movabsq and then load from there the floating-point value. Fixes <rdar://problem/17674628>. llvm-svn: 215595
* [FastISel][X86] Use XOR to materialize the "0" value.Juergen Ributzka2014-08-135-11/+34
| | | | llvm-svn: 215594
* [FastISel][X86] Emit more efficient instructions for integer constant ↵Juergen Ributzka2014-08-133-212/+177
| | | | | | | | | | | | | materialization. This mostly affects the i64 value type, which always resulted in an 15byte mobavsq instruction to materialize any constant. The custom code checks the value of the immediate and tries to use a different and smaller mov instruction when possible. This fixes <rdar://problem/17420988>. llvm-svn: 215593
* clang/test/Index/index-module.m: Tweak expressions to meet dos path on win32.NAKAMURA Takumi2014-08-131-2/+2
| | | | llvm-svn: 215592
* [FastISel][AArch64] Make use of the zero register when possible.Juergen Ributzka2014-08-135-16/+59
| | | | | | | | | | This change materializes now the value "0" from the zero register. The zero register can be folded by several instruction, so no materialization is need at all. Fixes <rdar://problem/17924413>. llvm-svn: 215591
* ClangTidyTests: Suppress FixHeaderGuards on win32 for now.NAKAMURA Takumi2014-08-131-0/+3
| | | | | FIXME: It seems this might be incompatible to dos path. Investigating. llvm-svn: 215590
* [CMake] Update libdeps in clangTidyLLVMModule.NAKAMURA Takumi2014-08-131-0/+1
| | | | llvm-svn: 215589
* [FastISel] Let the target decide first if it wants to materialize a constant.Juergen Ributzka2014-08-1310-87/+56
| | | | | | | | | | | | | | | | | | | | | | | | This changes the order in which FastISel tries to materialize a constant. Originally it would try to use a simple target-independent approach, which can lead to the generation of inefficient code. On X86 this would result in the use of movabsq to materialize any 64bit integer constant - even for simple and small values such as 0 and 1. Also some very funny floating-point materialization could be observed too. On AArch64 it would materialize the constant 0 in a register even the architecture has an actual "zero" register. On ARM it would generate unnecessary mov instructions or not use mvn. This change simply changes the order and always asks the target first if it likes to materialize the constant. This doesn't fix all the issues mentioned above, but it enables the targets to implement such optimizations. Related to <rdar://problem/17420988>. llvm-svn: 215588
* [MachineCombiner] Removal of dangling DBG_VALUES after combining [20598]Gerolf Hoflehner2014-08-132-3/+2
| | | | | | | | This is a cleaner solution to the problem described in r215431. When instructions are combined a dangling DBG_VALUE is removed. This resolves bug 20598. llvm-svn: 215587
* [FastISel][X86] Refactor constant materialization. NFCI.Juergen Ributzka2014-08-131-54/+67
| | | | | | | Split the constant materialization code into three separate helper functions for Integer-, Floating-Point-, and GlobalValue-Constants. llvm-svn: 215586
* test/CodeGen: Don't rely on a value's number in check linesJustin Bogner2014-08-131-3/+4
| | | | | | | The tests in r215568 hard code a value as %0 in their checks. This isn't correct in asserts builds. llvm-svn: 215585
* [FastISel][ARM] Use MOVT/MOVW if the subtarget requests it.Juergen Ributzka2014-08-132-2/+5
| | | | | | | | This change is also in preparation for a future change to make sure that the constant materialization uses MOVT/MOVW when available and not a load from the constant pool. llvm-svn: 215584
* [FastISel][ARM] Fix a bug in the integer materialization code.Juergen Ributzka2014-08-131-1/+3
| | | | | | | | | | | | getRegClassFor returns the incorrect register class when in Thumb2 mode. This fix simply manually selects the register class as in the code just a few lines above. There is no test case for this code, because the code is currently unreachable. This will be changed in a future commit and existing test cases will exercise this code. llvm-svn: 215583
* [FastISel][AArch64] Cleanup constant materialization code. NFCI.Juergen Ributzka2014-08-131-26/+30
| | | | | | Cleanup and prepare constant materialization code for future commits. llvm-svn: 215582
* Objective-C. Minor refactoring of my last patch.Fariborz Jahanian2014-08-133-9/+10
| | | | | | // rdar://16808765 llvm-svn: 215581
* [Cleanup] Utility function to erase instruction and mark DBG_ValuesGerolf Hoflehner2014-08-133-12/+30
| | | | | | | | | | New function to erase a machine instruction and mark DBG_VALUE for removal. A DBG_VALUE is marked for removal when it references an operand defined in the instruction. Use the new function to cleanup code in dead machine instruction removal pass. llvm-svn: 215580
* [modules] Fix a rejects-valid resulting from emitting an inline functionRichard Smith2014-08-133-1/+33
| | | | | | | | recursively within the emission of another inline function. This ultimately led to us emitting the same inline function definition twice, which we then rejected because we believed we had a mangled name conflict. llvm-svn: 215579
* AArch64: replace __func__ with LLVM_FUNCTION_NAMEHans Wennborg2014-08-132-123/+123
| | | | | | MSVC doesn't define __func__. llvm-svn: 215578
* Objective-C. This patch is to resolve the method used in methodFariborz Jahanian2014-08-136-4/+147
| | | | | | | expression to the best method found in global method pools. This is wip. // rdar://16808765 llvm-svn: 215577
* [MachineDominatorTree] Provide a method to inform a MachineDominatorTree that aQuentin Colombet2014-08-133-26/+145
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | critical edge has been split. The MachineDominatorTree will when lazy update the underlying dominance properties when require. ** Context ** This is a follow-up of r215410. Each time a critical edge is split this invalidates the dominator tree information. Thus, subsequent queries of that interface will be slow until the underlying information is actually recomputed (costly). ** Problem ** Prior to this patch, splitting a critical edge needed to query the dominator tree to update the dominator information. Therefore, splitting a bunch of critical edges will likely produce poor performance as each query to the dominator tree will use the slow query path. This happens a lot in passes like MachineSink and PHIElimination. ** Proposed Solution ** Splitting a critical edge is a local modification of the CFG. Moreover, as soon as a critical edge is split, it is not critical anymore and thus cannot be a candidate for critical edge splitting anymore. In other words, the predecessor and successor of a basic block inserted on a critical edge cannot be inserted by critical edge splitting. Using these observations, we can pile up the splitting of critical edge and apply then at once before updating the DT information. The core of this patch moves the update of the MachineDominatorTree information from MachineBasicBlock::SplitCriticalEdge to a lazy MachineDominatorTree. ** Performance ** Thanks to this patch, the motivating example compiles in 4- minutes instead of 6+ minutes. No test case added as the motivating example as nothing special but being huge! The binaries are strictly identical for all the llvm test-suite + SPECs with and without this patch for both Os and O3. Regarding compile time, I observed only noise, although on average I saw a small improvement. <rdar://problem/17894619> llvm-svn: 215576
* Fix (re-)creation of unittest lit.site.cfg for clang-tools-extra.Benjamin Kramer2014-08-131-1/+1
| | | | | | | This has been hiding really well. Hopefully brings the builders suffering from outdated lit.site.cfg files back to life. llvm-svn: 215575
OpenPOWER on IntegriCloud