Because we don't have a separate negate( ) function, 0 - NaN does double-duty as the IEEE-754 negate( ) operation, which (unlike most FP ops) *does* attach semantic meaning to the signbit of NaN.
llvm-svn: 210428
Avoid changing behaviour for everyone who's used to the traditional ghostview
UI, especially since it knows how to stay in the foreground unlike xdg-open.
Amendment to r210147.
llvm-svn: 210148
Replace the crufty build-time configure checks for program paths with
equivalent runtime logic.
This lets users install graphing tools as needed without having to reconfigure
and rebuild LLVM, while eliminating a long chain of inappropriate compile
dependencies that included GUI programs and the windowing system.
Additional features:
* Support the OS X 'open' command to view graphs generated by any of the
Graphviz utilities. This is an alternative to the Graphviz OS X UI which is
no longer available on Mountain Lion.
* Produce informative log output upon failure to indicate which programs can
be installed to view graphs.
Ping me if this doesn't work for your particular environment.
llvm-svn: 210001
Introduce the support structures necessary to deal with the Windows ARM EH data.
These definitions are extremely aggressive about assertions to aid future use
for generation of the entries and subsequent decoding.
The names for the various fields are meant to reflect the names used by the
Visual Studio toolchain to aid communication.
Due to the complexity in reading a few of the values, there are a couple of
additional utility functions to decode the information.
In general, there are two ways to encode the unwinding information:
- packed, which places the data inline into the
_IMAGE_ARM_RUNTIME_FUNCTION_ENTRY structure.
- unpacked, which places the data into auxiliary structures placed into the
.xdata section.
The set of structures allow reading of data in either encoding, with the minor
caveat that epilogue scopes need to be decoded manually by constructing the
structure from the data returned by the RuntimeFunction structure.
These definitions are meant for read-only access at the current point as the
first use of them will be to decode the exception information.
llvm-svn: 209998
Input YAML file might contain multiple object file definitions.
New option `-docnum` allows to specify an ordinal number (starting from 1)
of definition used for an object file generation.
Patch reviewed by Sean Silva.
llvm-svn: 209967
On x64, windows.h doesn't include intrin.h for intrinsics. It just
declares them in the global namespace and uses them, expecting the
compiler to lower it as a builtin. We basically need to do this in
clang, eventually.
llvm-svn: 208023
Tested that the right -target-cpu is set in the clang -cc1 command line
when running "clang -march=native -E -v - </dev/null" on both an FX-8150
and an FX-8350. Both are family 15h; the FX-8150 (Bulldozer processor)
reports a model number of 1, and the FX-8350 (Piledriver processor)
reports a model number of 2.
llvm-svn: 207973
Change `BlockFrequency` to defer to `BranchProbability::scale()` and
`BranchProbability::scaleByInverse()`.
This removes `BlockFrequency::scale()` from its API (and drops the
ability to see the remainder), but the only user was the unit tests. If
some code in the future needs an API that exposes the remainder, we can
add something to `BranchProbability`, but I find that unlikely.
llvm-svn: 207550
each line. This is particularly nice for tracking which run of
a particular pass over a particular function was slow.
This also required making the TimeValue string much more useful. First,
there is a standard format for writing out a date and time. Let's use
that rather than strings that would have to be parsed. Second, actually
output the nanosecond resolution that timevalue claims to have.
This is proving useful working on PR19499, so I figured it would be
generally useful to commit.
llvm-svn: 207385
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
declaration. GCC 4.7 appears to get hopelessly confused by declaring
this function within a member function of a class template. Go figure.
llvm-svn: 206152
abstract interface. The only user of this functionality is the JIT
memory manager and it is quite happy to have a custom type here. This
removes a virtual function call and a lot of unnecessary abstraction
from the common case where this is just a *very* thin vaneer around
a call to malloc.
Hopefully still no functionality changed here. =]
llvm-svn: 206149
slabs rather than embedding a singly linked list in the slabs
themselves. This has a few advantages:
- Better utilization of the slab's memory by not wasting 16-bytes at the
front.
- Simpler allocation strategy by not having a struct packed at the
front.
- Avoids paging every allocated slab in just to traverse them for
deallocating or dumping stats.
The latter is the really nice part. Folks have complained from time to
time bitterly that tearing down a BumpPtrAllocator, even if it doesn't
run any destructors, pages in all of the memory allocated. Now it won't.
=]
Also resolves a FIXME with the scaling of the slab sizes. The scaling
now disregards specially sized slabs for allocations larger than the
threshold.
llvm-svn: 206147
Don't quote octal compatible strings if they are only two wide, they
aren't ambiguous.
This reverts commit r205857 which reverted r205857.
llvm-svn: 205914
YAMLIO would turn a BinaryRef into the string 0000000004000000.
However, the leading zero causes parsers to interpret it as being an
octal number instead of a hexadecimal one.
Instead, escape such strings as needed.
llvm-svn: 205839
This avoids an extra copy during decompression and avoids the use of
MemoryBuffer which is a weirdly esoteric device that includes unrelated
concepts like "file name" (its rather generic name is a bit misleading).
Similar refactoring of zlib::compress coming up.
llvm-svn: 205676
This generalises the object file type parsing to all Windows environments. This
is used by cygwin as well as MSVC environments for MCJIT. This also makes the
triple more similar to Chandler's suggestion of a separate field for the object
file format.
llvm-svn: 205219
parameters rather than runtime parameters.
There is only one user of these parameters and they are compile time for
that user. Making these compile time seems to better reflect their
intended usage as well.
llvm-svn: 205143
That causes references to them to be weak references which can collapse
to null if no definition is provided. We call these functions
unconditionally, so a definition *must* be provided. Make the
definitions provided in the .cpp file weak by re-declaring them as weak
just prior to defining them. This should keep compilers which cannot
attach the weak attribute to the definition happy while actually
resolving the symbols correctly during the link.
You might ask yourself upon reading this commit log: how did *any* of
this work before? Well, fun story. It turns out we have some code in
Support (BumpPtrAllocator) which both uses virtual dispatch and has
out-of-line vtables used by that virtual dispatch. If you move the
virtual dispatch into its header in *just* the right way, the optimizer
gets to devirtualize, and remove all references to the vtable. Then the
sad part: the references to this one vtable were the only strong symbol
uses in the support library for llvm-tblgen AFAICT. At least, after
doing something just like this, these symbols stopped getting their weak
definition and random calls to them would segfault instead.
Yay software.
llvm-svn: 205137
If the environment is unknown and no object file is provided, then assume an
"MSVC" environment, otherwise, set the environment to the object file format.
In the case that we have a known environment but a non-native file format for
Windows (COFF) which is used for MCJIT, then append the custom file format to
the triple as an additional component.
This fixes the MCJIT tests on Windows.
llvm-svn: 205130
This will fix cross-compiling buildbots (e.g. cygwin). This is in the same vein
as SVN r205070. Apply this to fix the cross-compiling scenario, even though the
preferred solution is to update the build system to normalize the embedded
triple rather than perform this at runtime every time. This is meant to tide us
over until that approach is fleshed out and applied.
llvm-svn: 205120
This adds a second implementation of the AArch64 architecture to LLVM,
accessible in parallel via the "arm64" triple. The plan over the
coming weeks & months is to merge the two into a single backend,
during which time thorough code review should naturally occur.
Everything will be easier with the target in-tree though, hence this
commit.
llvm-svn: 205090
BumpPtrAllocator significantly less strange by making it a simple
function of the number of slabs allocated rather than by making it
a recurrance. I *think* the previous behavior was essentially that the
size of the slabs would be doubled after the first 128 were allocated,
and then doubled again each time 64 more were allocated, but only if
every allocation packed perfectly into the slab size. If not, the wasted
space wouldn't be counted toward increasing the size, but allocations
over the size threshold *would*. And since the allocations over the size
threshold might be much larger than the slab size, this could have
somewhat surprising consequences where we rapidly grow the slab size.
This currently requires adding state to the allocator to track the
number of slabs currently allocated, but that isn't too bad. I'm
planning further changes to the allocator that will make this state fall
out even more naturally.
It still doesn't fully decouple the growth rate from the allocations
which are over the size threshold. That fix is coming later.
This specific fix will allow making the entire thing into a more
stateless device and lifting the parameters into template parameters
rather than runtime parameters.
llvm-svn: 204993
Construct a uniform Windows target triple nomenclature which is congruent to the
Linux counterpart. The old triples are normalised to the new canonical form.
This cleans up the long-standing issue of odd naming for various Windows
environments.
There are four different environments on Windows:
MSVC: The MS ABI, MSVCRT environment as defined by Microsoft
GNU: The MinGW32/MinGW32-W64 environment which uses MSVCRT and auxiliary libraries
Itanium: The MSVCRT environment + libc++ built with Itanium ABI
Cygnus: The Cygwin environment which uses custom libraries for everything
The following spellings are now written as:
i686-pc-win32 => i686-pc-windows-msvc
i686-pc-mingw32 => i686-pc-windows-gnu
i686-pc-cygwin => i686-pc-windows-cygnus
This should be sufficiently flexible to allow us to target other windows
environments in the future as necessary.
llvm-svn: 204977
Add a utility function to convert the Windows path separator to Unix style path
separators. This is used by a subsequent change in clang to enable the use of
Windows SDK headers on Linux.
llvm-svn: 203611
Before this patch the unix code for creating hardlinks was unused. The code
for creating symbolic links was implemented in lib/Support/LockFileManager.cpp
and the code for creating hard links in lib/Support/*/Path.inc.
The only use we have for these is in LockFileManager.cpp and it can use both
soft and hard links. Just have a create_link function that creates one or the
other depending on the platform.
llvm-svn: 203596
This is a preliminary setup change to support a renaming of Windows target
triples. Split the object file format information out of the environment into a
separate entity. Unfortunately, file format was previously treated as an
environment with an unknown OS. This is most obvious in the ARM subtarget where
the handling for macho on an arbitrary platform switches to AAPCS rather than
APCS (as per Apple's needs).
llvm-svn: 203160
This reverts commits r203136, r203137, and r203138.
This code doesn't build on Windows. Even on Vista+, Windows requires
elevated privileges to create a symlink. Therefore we can't use
symlinks in the compiler. We'll have to find another approach.
llvm-svn: 203143
There was a race where:
- The LockFileManager tries to own the lock file and fails.
- The other owner then releases and removes the lock file.
- The LockFileManager tries to read the owner info from the lock file but fails now.
In such a case have LockFileManager try to get ownership again, instead of error'ing out.
llvm-svn: 203138
Hard links do not work on SMB network directories, and it causes us to fail
to build clang module files if the module cache is in such a directory.
rdar://15944959
llvm-svn: 203137
This compiles with no changes to clang/lld/lldb with MSVC and includes
overloads to various functions which are used by those projects and llvm
which have OwningPtr's as parameters. This should allow out of tree
projects some time to move. There are also no changes to libs/Target,
which should help out of tree targets have time to move, if necessary.
llvm-svn: 203083
When using a //net/ path, we were transforming the trailing / into a '.'
when the path was just the root path and we were iterating backwards.
Forwards iteration and other kinds of root path (C:\, /) were already
correct.
llvm-svn: 202999
This will allow external callers of these functions to switch over time
rather than forcing a breaking change all a once. These particular
functions were determined by building clang/lld/lldb.
llvm-svn: 202959
a bit surprising, as the class is almost entirely abstracted away from
any particular IR, however it encodes the comparsion predicates which
mutate ranges as ICmp predicate codes. This is reasonable as they're
used for both instructions and constants. Thus, it belongs in the IR
library with instructions and constants.
llvm-svn: 202838
Breaks the MSVC build.
DataStream.cpp(44): error C2552: 'llvm::Statistic::Value' : non-aggregates cannot be initialized with initializer list
llvm-svn: 202731
With C++11 we finally have a standardized way to specify atomic operations. Use
them to replace the existing custom implemention. Sadly the translation is not
entirely trivial as std::atomic allows more fine-grained control over the
atomicity. I tried to preserve the old semantics as well as possible.
Differential Revision: http://llvm-reviews.chandlerc.com/D2915
llvm-svn: 202730
lib/Support/RWMutex.cpp contains an implementation of RWMutex that
uses pthread_rwlock, but when pthread_rwlock is not available (such as
under NaCl, when using newlib), it silently falls back to using the
no-op definition in lib/Support/Unix/RWMutex.inc, which is not
thread-safe.
Fix this case to be thread-safe by using a normal mutex.
Differential Revision: http://llvm-reviews.chandlerc.com/D2892
llvm-svn: 202570
Tools that use the CommandLine library currently exit with an error
when invoked with -version or -help. This is unusual and non-standard,
so we'll fix them to exit successfully instead.
I don't expect that anyone relies on the current behaviour, so this
should be a fairly safe change.
llvm-svn: 202530
target_link_libraries(INTERFACE) doesn't bring inter-target dependencies in add_library,
although final targets have dependencies to whole dependent libraries.
It makes most libraries can be built in parallel.
target_link_libraries(PRIVATE) is used to shaared library.
Each dependent library is linked to the target.so, and its user will not see its grandchildren.
For example,
- libclang.so has sufficient libclang*.a(s).
- c-index-test requires just only libclang.so.
FIXME: lld is tweaked minimally. Adding INTERFACE in each library would be better thing.
llvm-svn: 202241
After this I will set the default back to F_None. The advantage is that
before this patch forgetting to set F_Binary would corrupt a file on windows.
Forgetting to set F_Text produces one that cannot be read in notepad, which
is a better failure mode :-)
llvm-svn: 202052
Before this patch they would take an boolean argument to say if the path
already existed. This was redundant with the returned error_code which is able
to represent that. This allowed for callers to incorrectly check only the
existed flag instead of first checking the error code.
Instead, pass in a boolean flag to say if the previous (non-)existence should be
an error or not.
Callers of the of the old simple versions are not affected. They still ignore
the previous (non-)existence as they did before.
llvm-svn: 201979
The LLVMSupport library implementation consolidates all dependencies on
system libraries. Move the logic gathering system libraries out of
'cmake/modules/LLVM-Config.cmake' and into 'lib/Support/CMakeLists.txt'.
Use the target_link_libraries() command there to tell CMake about the
link dependencies of the LLVMSupport implementation. CMake will
automatically propagate this to all targets that link LLVMSupport
directly or indirectly.
We still need to build knowledge of system library dependencies into
'llvm-config'. Store the list of libraries needed in a property on
LLVMSupport and teach 'tools/llvm-config/CMakeLists.txt' to retrieve it
from there.
Drop all calls to 'link_system_libs' and 'get_system_libs' from our
CMake code. Replace their implementations with a warning that explains
the calls are no longer necessary. Also drop from 'LLVMConfig.cmake'
the HAVE_* and related variables that were published there only to allow
'get_system_libs' to run outside our build process.
Contributed by Brad King.
llvm-svn: 201969
This is an optimistic version of create_diretories: it tries to create the
directory first and looks at the parent only if that fails.
Running strace on "mkdir -p" shows that it is pessimistic, calling mkdir on
every element of the path. We could implement that if needed.
In any case, with both strategies there is no reason to call stat, just check
the return of mkdir.
llvm-svn: 201347
I found that swapping the order of some header files helped fix a
build issue that we're seeing on mingw32. Without the swap, windows.h
was being included before _WIN32_WINNT was being defined and the
CreateHardLinkW function was #ifdef'd out.
It looks like the header is mainly used to get the SHGetFolderPathW
function, so I don't think that there'll be much fallout from the
switch.
Suggested by Alex Crichton. Thanks!
llvm-svn: 201230
An intermediate solution until the problems with analyzer plugins linking with
llvm/Support and causing assertions due to duplicate GeneralCategory are solved.
llvm-svn: 200981
Summary:
The check performed in the comparator is invalid, as some STL
implementations enforce strict weak ordering by calling the comparator with the
same value. This check was also in a wrong place: the assertion would only fire
when -help was used. The new check is performed each time the category is
registered (we are not going to have thousands of them, so it's fine to do it in
O(N^2)).
Reviewers: jordan_rose
Reviewed By: jordan_rose
CC: cfe-commits, alexmc
Differential Revision: http://llvm-reviews.chandlerc.com/D2699
llvm-svn: 200853
ISSUE:
On Ubuntu 12.04 LTS, arc4random is provided by libbsd.so, which is a
transitive dependency of libedit. If a system had libedit on it that
was implemented in terms of libbsd.so, then the arc4random test,
previously implemented as a linker test, would succeed with -ledit.
However, on Ubuntu this would also require a #include <bsd/stdlib.h>.
This caused a build breakage on configure-based Ubuntu 12.04 with
libedit installed.
FIX:
This fix changes configure to test for arc4random by searching for it
in the standard header files. On Ubuntu 12.04, this test now properly
fails to find arc4random as it is not defined in the default header
locations. It also tweaks the #define names to match the output of the
header check command, which is slightly different than the linker
function check #defines.
I tested the following scenarios:
(1) Ubuntu 12.04 without the libedit package [did not find arc4random,
as expected]
(2) Ubuntu 12.04 with libedit package [properly did not find
arc4random, as expected]
(3) Ubuntu 12.04 with most recent libedit, custom built, and not
dependent on libbsd.so [properly did not find arc4random, as
expected].
(4) FreeBSD 10.0B1 [properly found arc4random, as expected]
llvm-svn: 200819
Zachary Turner