summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Carry facts about nullness and undef across GC relocationPhilip Reames2014-12-293-2/+90
| | | | | | | | | | | | | | | This change implements four basic optimizations: If a relocated value isn't used, it doesn't need to be relocated. If the value being relocated is null, relocation doesn't change that. (Technically, this might be collector specific. I don't know of one which it doesn't work for though.) If the value being relocated is undef, the relocation is meaningless. If the value being relocated was known nonnull, the relocated pointer also isn't null. (Since it points to the same source language object.) I outlined other planned work in comments. Differential Revision: http://reviews.llvm.org/D6600 llvm-svn: 224968
* Fix build breakageDavid Majnemer2014-12-291-1/+2
| | | | | | That's what I get for last second changes... llvm-svn: 224967
* Parse: Recover more gracefully from extra :: tokens before a {David Majnemer2014-12-292-1/+13
| | | | | | | Instead of crashing, recover by eating the extra trailing scope qualifier. This means we will treat 'struct A:: {' as 'struct A {'. llvm-svn: 224966
* Refine the notion of MayThrow in LICM to include a header specific versionPhilip Reames2014-12-292-8/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In LICM, we have a check for an instruction which is guaranteed to execute and thus can't introduce any new faults if moved to the preheader. To handle a function which might unconditionally throw when first called, we check for any potentially throwing call in the loop and give up. This is unfortunate when the potentially throwing condition is down a rare path. It prevents essentially all LICM of potentially faulting instructions where the faulting condition is checked outside the loop. It also greatly diminishes the utility of loop unswitching since control dependent instructions - which are now likely in the loops header block - will not be lifted by subsequent LICM runs. define void @nothrow_header(i64 %x, i64 %y, i1 %cond) { ; CHECK-LABEL: nothrow_header ; CHECK-LABEL: entry ; CHECK: %div = udiv i64 %x, %y ; CHECK-LABEL: loop ; CHECK: call void @use(i64 %div) entry: br label %loop loop: ; preds = %entry, %for.inc %div = udiv i64 %x, %y br i1 %cond, label %loop-if, label %exit loop-if: call void @use(i64 %div) br label %loop exit: ret void } The current patch really only helps with non-memory instructions (i.e. divs, etc..) since the maythrow call down the rare path will be considered to alias an otherwise hoistable load. The one exception is that it does kick in for loads which are known to be invariant without regard to other possible stores, i.e. those marked with either !invarant.load metadata of tbaa 'is constant memory' metadata. Differential Revision: http://reviews.llvm.org/D6725 llvm-svn: 224965
* [cmake/multilib] Teach llgo to respect the LLVM_LIBDIR_SUFFIX variable forChandler Carruth2014-12-293-23/+50
| | | | | | | | | | | | | | | | | multilib build and installs. Summary: This requires introducing a generated header to encapsulate the LLVM_LIBDIR_SUFFIX value from the build system and push it into the go code. From there, I've adjusted the gllgo code to systematically use this rather than a raw "lib". This requires some awkwardness as one of the flags *must* be "lib"-relative for compatibility with how gccgo works. For that flag, we use ".." to back up a directory and then go into the proper lib directory. Differential Revision: http://reviews.llvm.org/D6795 llvm-svn: 224964
* PR22051: Missing debug location on calls in dtor thunks in Windows.David Blaikie2014-12-292-1/+23
| | | | llvm-svn: 224963
* [go] Teach the go cmake build functions to funnel the include directories ↵Chandler Carruth2014-12-291-1/+6
| | | | | | | | | | | | | | down into the cgo-setup variables of llvm-go. Summary: This in turn allows us to use #includes with cgo that rely on CMake provided include directories which is particularly useful for handling generated headers that aren't reasonable to put in an "installable" location. Differential Revision: http://reviews.llvm.org/D6798 llvm-svn: 224962
* Loading from null is valid outside of addrspace 0Philip Reames2014-12-292-10/+30
| | | | | | | | | | This patches fixes a miscompile where we were assuming that loading from null is undefined and thus we could assume it doesn't happen. This transform is perfectly legal in address space 0, but is not neccessarily legal in other address spaces. We really should introduce a hook to control this property on a per target per address space basis. We may be loosing valuable optimizations in some address spaces by being too conservative. Original patch by Thomas P Raoux (submitted to llvm-commits), tests and formatting fixes by me. llvm-svn: 224961
* Use std::find_if instead of manual loop.David Blaikie2014-12-291-8/+4
| | | | llvm-svn: 224960
* Convert test to llvm-readobj. NFC.Rafael Espindola2014-12-291-16/+41
| | | | llvm-svn: 224959
* Crash even less on malformed attributes in an incorrect location.Nico Weber2014-12-292-5/+8
| | | | | | | | | | | This is a follow-up to r224915. This adds a bit more line noise to the tests added in that revision to make sure the parser is ready for a toplevel decl after each incorrect line. Use this to move the tests up to where they belong. This uncovered that the early return was missing a call to ActOnTagDefinitionError(), so add that. (Also fixes at least one of the crashes on SLi's bot.) llvm-svn: 224958
* [Hexagon] Adding allocframe, post-increment circular immediate stores, ↵Colin LeMahieu2014-12-294-18/+183
| | | | | | post-increment circular register stores, and bit reversed post-increment stores. llvm-svn: 224957
* Fix use-after-destruction introduced in r224924.Alexey Samsonov2014-12-291-1/+2
| | | | | | | | getMainExecutable() returns a std::string, assigning its result to StringRef immediately creates a dangling pointer. This was detected by half-broken fast-MSan-bootstrap bot. llvm-svn: 224956
* [Hexagon] Fixing 224952 where an addressing mode update was missed.Colin LeMahieu2014-12-291-1/+1
| | | | llvm-svn: 224955
* Driver: convert a couple more instances to range based loopsSaleem Abdulrasool2014-12-291-6/+4
| | | | | | | More conversion to range based for loops rather than direct iterators with dereferencing. NFC. llvm-svn: 224954
* Remove unnecessary StringRef->std::string conversion.Alexey Samsonov2014-12-291-1/+1
| | | | llvm-svn: 224953
* [Hexagon] Adding post-increment register form stores and register-immediate ↵Colin LeMahieu2014-12-299-182/+278
| | | | | | form stores with tests. llvm-svn: 224952
* [Hexagon] Replacing the remaining postincrement stores with versions that ↵Colin LeMahieu2014-12-294-59/+60
| | | | | | have encoding bits. llvm-svn: 224951
* Convert test to FileCheck. NFC.Rafael Espindola2014-12-291-876/+877
| | | | llvm-svn: 224950
* [Hexagon] Renaming old multiclass for removal. Adding post-increment store ↵Colin LeMahieu2014-12-294-9/+118
| | | | | | classes and instruction defs. llvm-svn: 224949
* [py3] Teach the CMake build to reject Python versions older than 2.7.Chandler Carruth2014-12-291-1/+7
| | | | | | | Continue to require Python 2 however as recent experiments suggest LLDB's build requires it. llvm-svn: 224948
* [py3] Make this test compatible with Python 3 where bytes andChandler Carruth2014-12-291-8/+8
| | | | | | | | strings don't mix so easily. This fixes the last remaining failure I have in 'check-all' on a system with both Python3 and and Python2 installed. llvm-svn: 224947
* Remove darwin_fat.mk.Alexey Samsonov2014-12-291-56/+0
| | | | | | | | | | | | | | | | | Summary: Its seems to be replaced by clang_darwin.mk in the Makefile-based build, and is only referenced in unittest scripts, which are broken for a long time now. Test Plan: n/a Reviewers: bob.wilson Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6574 llvm-svn: 224946
* Parse: Ignore '::' in 'struct :: {'David Majnemer2014-12-293-13/+16
| | | | | | | Let's pretend that we didn't see the '::' instead of go on believing that we've got some anonymous, but globally qualified, struct. llvm-svn: 224945
* Driver: convert a number of loops to range basedSaleem Abdulrasool2014-12-291-33/+10
| | | | | | | Iterate over the arguments via range based for loops rather than iterators and explicitly dereferencing them. NFC. llvm-svn: 224944
* Add an assertion to verify a container is non-empty before calling 'back()'David Blaikie2014-12-291-0/+1
| | | | | | | This would've helped stabilize/deflake some failures that were seen after some recent changes. llvm-svn: 224943
* Reapply debug info changes now that r224385 has been recommitted to clang ↵David Blaikie2014-12-292-2/+2
| | | | | | (in r224941) llvm-svn: 224942
* Reapply "DebugInfo: Generalize debug info location handling"David Blaikie2014-12-2918-195/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally committed in r224385 and reverted in r224441 due to concerns this change might've introduced a crash. Turns out this change fixes the crash introduced by one of my earlier more specific location handling changes (those specific fixes are reverted by this patch, in favor of the more general solution). Original commit message: This is a more scalable (fixed in mostly one place, rather than many places that will need constant improvement/maintenance) solution to several commits I've made recently to increase source fidelity for subexpressions. This resetting had to be done at the DebugLoc level (not the SourceLocation level) to preserve scoping information (if the resetting was done with CGDebugInfo::EmitLocation, it would've caused the tail end of an expression's codegen to end up in a potentially different scope than the start, even though it was at the same source location). The drawback to this is that it might leave CGDebugInfo out of sync. Ideally CGDebugInfo shouldn't have a duplicate sense of the current SourceLocation, but for now it seems it does... - I don't think I'm going to tackle removing that just now. I expect this'll probably cause some more buildbot fallout & I'll investigate that as it comes up. Also these sort of improvements might be starting to show a weakness/bug in LLVM's line table handling: we don't correctly emit is_stmt for statements, we just put it on every line table entry. This means one statement split over multiple lines appears as multiple 'statements' and two statements on one line (without column info) are treated as one statement. I don't think we have any IR representation of statements that would help us distinguish these cases and identify the beginning of each statement - so that might be something we need to add (possibly to the lexical scope chain - a scope for each statement). This does cause some problems for GDB and possibly other DWARF consumers. llvm-svn: 224941
* [X86] Fix some cases where some 8-bit instructions were marked as being ↵Craig Topper2014-12-291-18/+24
| | | | | | convertible to three address instructions, but aren't really. llvm-svn: 224940
* [X86] Add the 0x82 instructions to the disassebmler. They are identical in ↵Craig Topper2014-12-291-6/+35
| | | | | | functionality to the 0x80 opcode instructions, but are not valid in 64-bit mode. llvm-svn: 224939
* [x86] Refactor some tablegen instruction info classes slightly to prepare ↵Craig Topper2014-12-291-29/+28
| | | | | | for another change. NFC. llvm-svn: 224938
* [x86] Remove unused classes from tablegen instruction info.Craig Topper2014-12-291-23/+0
| | | | llvm-svn: 224937
* Add segmented stack support for DragonFlyBSD.Rafael Espindola2014-12-294-3/+122
| | | | | | Patch by Michael Neumann. llvm-svn: 224936
* Refactor duplicated code.Rafael Espindola2014-12-2915-104/+74
| | | | | | No intended functionality change. llvm-svn: 224935
* Effectively revert r151058 which caused Clang's unwind.h to defer toChandler Carruth2014-12-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | libunwind in all cases when installed. At the time, Clang's unwind.h didn't provide huge chunks of the LSB-specified unwind interface, and was generally too aenemic to use for real software. However, it has since then become a strict superset of the APIs provided by libunwind on Linux. Notably, you cannot compile llgo's libgo library against libunwind, but you can against Clang's unwind.h. So let's just use our header. =] I've checked pretty thoroughly for any incompatibilities, and I am not aware of any. An open question is whether or not we should continue to munge GNU_SOURCE here. I didn't touch that as it potentially has compatibility implications on systems I cannot easily test -- Darwin. If a Darwin maintainer can verify that this is in fact unnecessary and remove it, cool. Until then, leaving it in makes this change a no-op there, and only really relevant on Linux systems where it is pretty clearly the right way to go. llvm-svn: 224934
* Add a missing declaration to our unwind.h implementation. This isChandler Carruth2014-12-291-0/+2
| | | | | | | | | necessary to be fully compatible with existing software that calls into the linux unwind code. You can find documentation of this API and why it exists in the discussion abot NPTL here: https://gcc.gnu.org/ml/gcc-patches/2003-09/msg00154.html llvm-svn: 224933
* Fix trivial signed/unsigned comparison warningsAndy Gibbs2014-12-292-5/+5
| | | | llvm-svn: 224932
* irgen: remove unused compiler.runtimetypespkg field.Peter Collingbourne2014-12-291-4/+0
| | | | llvm-svn: 224931
* [cmake/multilib] Teach LLDB to respect the multlib LLVM_LIBDIR_SUFFIXChandler Carruth2014-12-294-10/+10
| | | | | | | | | | | | | | | | | | | | | variable (now provided both by the normal parent LLVM CMake files and by the LLVMConfig.cmake file used by the standalone build). This allows LLDB to build into and install into correctly suffixed libdirs. This is especially significant for LLDB because the python extension building done by CMake directly uses multilib suffixes when the host OS does, and the host OS will not always look back and forth between them. As a consequence, before LLVM, Clang, and LLDB (and every other subproject) had support for using LLVM_LIBDIR_SUFFIX, you couldn't build or install LLDB on a multilib system with its python extensions enabled. With this patch (on top of all the others I have submitted throughout the project), I'm finally able to build and install LLDB on my system with Python support enabled. I'm also able to actually run the LLDB test suite, etc. Now, a *huge* number of the tests still fail on my Linux system, but hey, actually running them and them testing the debugger is a huge step forward. =D llvm-svn: 224930
* [cmake] Teach the standalone CMake build to find the Python interpreterChandler Carruth2014-12-291-0/+10
| | | | | | | | | | | the same way the LLVM CMake build does, notably using the proper CMake module and specifically requesting an older Python version. LLDB relies pretty heavily on not using Python 3 at this point, and without this patch it ends up trying to use Python 3 which ends quite badly. =] With this, I'm able to build LLDB in its standalone mode successfully on Linux when I have both Python 2.7 and Python 3.3 installed. llvm-svn: 224929
* [cmake/multilib] Support multilib libdir suffixes by applying theChandler Carruth2014-12-291-1/+2
| | | | | | | | | | LLVM_LIBDIR_SUFFIX variable to one place in the cmake file. This is all that I had to do to get everything from compiler-rt working for me, but there may be more work required if folks are relying on more parts of compiler-rt. Notably, I'm mostly using it for the sanitizers. llvm-svn: 224928
* [cmake/multilib] Teach libc++abi's CMake build to support multilibChandler Carruth2014-12-295-24/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | libdir suffixes like 'lib64' or 'lib32'. This support is currently very rhudimentary. We define a variable LIBCXXABI_LIBDIR_SUFFIX. In a standalone build of libc++abi this can be directly set as a cached variable to control the multilib suffix used. When building libc++abi within a larger LLVM build, it is hard wired to whatever LLVM libdir suffix has been selected. If this doesn't work for someone, just let me know. I'm happy to change it. Unfortunately, libc++abi's lit setup made this somewhat problematic to change. It was setting variables up in a way that caused the resulting build to not work with lit at all. To fix that, I've moved some variables around in the CMake build to more closely match where and how they are defined in the libc++ CMake build. This includes specifically defining a library root variable in the CMake build where the libdir suffix can be applied, and then using that rather than re-computing it from the object directory in the lit config. This is essentially new functionality for libc++abi so I don't expect it to have any impact for folks until they start setting these variables. However, I know libc++abi is built in a diverse set of environments so just let me know if this causes you any problems. llvm-svn: 224927
* [cmake/multilib] Teach libc++'s CMake build to support multilib libdirChandler Carruth2014-12-292-4/+11
| | | | | | | | | | | | | | | | | | suffixes like 'lib64' or 'lib32'. This support is currently very rhudimentary. We define a variable LIBCXX_LIBDIR_SUFFIX. In a standalone build of libc++ this can be directly set as a cached variable to control the multilib suffix used. When building libc++ within a larger LLVM build, it is hard wired to whatever LLVM libdir suffix has been selected. If this doesn't work for someone, just let me know. I'm happy to change it. This is essentially new functionality for libc++ so I don't expect it to have any impact for folks until they start setting these variables. However, I know libc++ is built in a diverse set of environments so just let me know if this causes you any problems. llvm-svn: 224926
* [multilib] Teach LLD's CMake build to use LLVM_LIBDIR_SUFFIX whichChandler Carruth2014-12-292-4/+4
| | | | | | | | allows it to support multilib suffixed hosts using lib64, etc. This variable is now available both in the direct LLVM build and from the LLVMConfig.cmake file used by standalone builds. llvm-svn: 224925
* [multilib] Teach Clang's code about multilib by threadingChandler Carruth2014-12-296-12/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a CLANG_LIBDIR_SUFFIX down from the build system and using that as part of the default resource dir computation. Without this, essentially nothing that uses the clang driver works when building clang with a libdir suffix. This is probably the single biggest missing piece of support for multilib as without this people could hack clang to end up installed in the correct location, but it would then fail to find its own basic resources. I know of at least one distro that has some variation on this patch to hack around this; hopefully they'll be able to use the libdir suffix functionality directly as the rest of these bits land. This required fixing a copy of the code to compute Clang's resource directory that is buried inside of the frontend (!!!). It had bitrotted significantly relative to the driver code. I've made it essentially a clone of the driver code in order to keep tests (which use cc1 heavily) passing. This copy should probably just be removed and the frontend taught to always rely on an explicit resource directory from the driver, but that is a much more invasive change for another day. I've also updated one test which actually encoded the resource directory in its checked output to tolerate multilib suffixes. Note that this relies on a prior LLVM commit to add a stub to the autoconf build system for this variable. llvm-svn: 224924
* [cmake] Teach the Clang CMake build to use LLVM_LIBDIR_SUFFIX for itsChandler Carruth2014-12-291-3/+3
| | | | | | | | | | | | 'lib' directories in the build. This variable is available now both as part of the normal LLVM build an as part of a standalone build as I've added it to the LLVMConfig.cmake output. With this change we should at least put libraries into the multilib directory correctly. It is the first step in getting Clang to be reasonably multilib aware. llvm-svn: 224923
* [multilib] Add support to the autoconf build to substituteChandler Carruth2014-12-293-0/+14
| | | | | | | | | | | | a CLANG_LIBDIR_SUFFIX variable. This is necessary before I can add support for using that variable to CMake and the C++ code in Clang, and the autoconf build system does all substitutions in the LLVM tree. As mentioned before, I'm not planning to add actual multilib support to the autoconf build, just enough stubs for it to keep playing nicely with the CMake build once that one has support. llvm-svn: 224922
* [cmake] Teach the llvm-config program to respect LLVM_LIBDIR_SUFFIX.Chandler Carruth2014-12-293-4/+9
| | | | | | | | | | | | | | For this to work, we have to encode it in the build variables and use it from llvm-config.cpp. I've tried to do this reasonably cleanly, but the code for llvm-config.cpp is pretty strange. However, with this, llvm-config stops giving the wrong answer when using LLVM_LIBDIR_SUFFIX. Note that the configure+make build just sets this to an empty string as that build system has zero support for multilib of any form. I'm not planning to add support there either, but this should leave a path for anyone that wanted to. llvm-svn: 224921
* [cmake] Push LLVM_LIBDIR_SUFFIX through to the LLVMConfig.cmake fileChandler Carruth2014-12-291-0/+2
| | | | | | | | | that is used by other projects to build against LLVM. This will allow subsequent patches to them to use LLVM_LIBDIR_SUFFIX, both when built as part of the larger LLVM build an as part of a standalone build against an installed set of LLVM libraries. llvm-svn: 224920
* [cmake] Start making LLVM_LIBDIR_SUFFIX effective by adding it toChandler Carruth2014-12-294-8/+9
| | | | | | | | | | | | | | | | | *numerous* places where it was missing in the CMake build. The primary change here is that the suffix is now actually used for all of the lib directories in the LLVM project's CMake. The various subprojects still need similar treatment. This is the first of a series of commits to try to make LLVM's cmake effective in a multilib Linux installation. I don't think many people are seriously using this variable so I'm hoping the fallout will be minimal. A somewhat unfortunate consequence of the nature of these commits is that until I land all of them, they will in part make the brokenness of our multilib support more apparant. At the end, things should actually work. llvm-svn: 224919
OpenPOWER on IntegriCloud