- mistakenly used get_current_dir() linux function
- replaced with getcwd/_getcwd as appropriate for current platform
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185225 91177308-0d34-0410-b5e6-96231b3b80d8
- lit tests verify that each line of input LLVM IR gets a !dbg node and a
corresponding entry of metadata that contains the line number
- unit tests verify that DebugIR works as advertised in the interface
- refactored some useful IR generation functionality from the MCJIT unit tests
so it can be reused
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185212 91177308-0d34-0410-b5e6-96231b3b80d8
Allow a BlockFrequency to be divided by a non-zero BranchProbability
with saturating arithmetic. This will be used to compute the frequency
of a loop header given the probability of leaving the loop.
Our long division algorithm already saturates on overflow, so that was a
freebie.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185184 91177308-0d34-0410-b5e6-96231b3b80d8
There are a few valid situation where we care about the structure inside a
directory, but not about the directory itself. A simple example is for unit
testing directory traversal.
PathV1 had a function like this, add one to V2 and port existing users of the
created temp file and delete it hack to using it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185059 91177308-0d34-0410-b5e6-96231b3b80d8
Zero is used by BlockFrequencyInfo as a special "don't know" value. It also
causes a sink for frequencies as you can't ever get off a zero frequency with
more multiplies.
This recovers a 10% regression on MultiSource/Benchmarks/7zip. A zero frequency
was propagated into an inner loop causing excessive spilling.
PR16402.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184584 91177308-0d34-0410-b5e6-96231b3b80d8
MIPS does not handle multiple relocations correctly, so two tests from the
unittests are expected to fail. These are:
- MCJITTest.return_global and
- MCJITTest.multiple_functions.
Until the multiple relocations are fixed, XFAIL the MCJIT unittests for
MIPS. This issue is tracked as Bug 16250.
Patch by Petar Jovanovic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184461 91177308-0d34-0410-b5e6-96231b3b80d8
The old isNormal is already functionally replaced by the method isFiniteNonZero
in r184350 and all references to said method were replaced in LLVM/clang in
r184356/134366.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184449 91177308-0d34-0410-b5e6-96231b3b80d8
This is the first patch in a series of patches to rename isNormal =>
isFiniteNonZero and isIEEENormal => isNormal. In order to prevent careless
errors on my part the overall plan is:
1. Add the isFiniteNonZero predicate with tests. I can do this in a method
independent of isNormal. (This step is this patch).
2. Convert all references to isNormal with isFiniteNonZero. My plan is to
comment out isNormal locally and continually convert isNormal references =>
isFiniteNonZero until llvm/clang compiles.
3. Remove old isNormal and rename isIEEENormal to isNormal.
4. Look through all of said references from patch 2 and see if we can simplify
them by using the new isNormal.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184350 91177308-0d34-0410-b5e6-96231b3b80d8
It was only used to implement ExecuteAndWait and ExecuteNoWait. Expose just
those two functions and make Execute and Wait implementations details.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183864 91177308-0d34-0410-b5e6-96231b3b80d8
Most clients have already been moved from Path V1 to V2. The ones using V1
now include PathV1.h explicitly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183801 91177308-0d34-0410-b5e6-96231b3b80d8
Specifically the following work was done:
1. If the operation was not implemented, I implemented it.
2. If the operation was already implemented, I just moved its location
in the APFloat header into the IEEE-754R 5.7.2 section. If the name was
incorrect, I put in a comment giving the true IEEE-754R name.
Also unittests have been added for all of the functions which did not
already have a unittest.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183179 91177308-0d34-0410-b5e6-96231b3b80d8
I additionally changed certain checks to use EXPECT_FALSE instead of a boolean
complement with EXPECT_TRUE.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182896 91177308-0d34-0410-b5e6-96231b3b80d8
Add a stringize method to make dumping a bit easier, and add a testcase
exercising a few different paths.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182692 91177308-0d34-0410-b5e6-96231b3b80d8
the C API to provide their own way of allocating JIT memory (both code
and data) and finalizing memory permissions (page protections, cache
flush).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182448 91177308-0d34-0410-b5e6-96231b3b80d8
the C API to provide their own way of allocating JIT memory (both code
and data) and finalizing memory permissions (page protections, cache
flush).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182408 91177308-0d34-0410-b5e6-96231b3b80d8
Revision r182233 partially reverted the change in r181200 to simplify
JIT unif test #ifdefs, because that change caused a link error on some
host operating systems where the export list requires the following
symbols to be defined:
JITTest_AvailableExternallyFunction
JITTest_AvailableExternallyGlobal
As discussed on the list, the commit reverts r182233 (and re-installs
the full r181200 change), and instead fixes the link problem by moving
those two symbols to the top of the file and unconditionally defining
them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182367 91177308-0d34-0410-b5e6-96231b3b80d8
The export list for this test requires the following symbols to be available:
JITTest_AvailableExternallyFunction
JITTest_AvailableExternallyGlobal
The change in r181200 commented them out, which caused the test to fail to
link, at least on Darwin. I have only reverted the change for arm, since I
can't test the other targets and since it sounds like that change was fixing
real problems for those other targets. It should be possible to rearrange the
code to keep those definitions outside the #ifdefs, but that should be done by
someone who can reproduce the problems that r181200 was trying to fix.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182233 91177308-0d34-0410-b5e6-96231b3b80d8
the JIT object (including XFAIL an ARM test that now needs fixing). Also renames
internal function for consistency.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182085 91177308-0d34-0410-b5e6-96231b3b80d8
BitVector/SmallBitVector::reference::operator bool remain implicit since
they model more exactly a bool, rather than something else that can be
boolean tested.
The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.
One behavior change (YAMLParser) was made, though no test case is
included as I'm not sure how to reach that code path. Essentially any
comparison of llvm::yaml::document_iterators would be invalid if neither
iterator was at the end.
This helped uncover a couple of bugs in Clang - test cases provided for
those in a separate commit along with similar changes to `operator bool`
instances in Clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181868 91177308-0d34-0410-b5e6-96231b3b80d8
EngineBuilder interface required a JITMemoryManager even if it was being used
to construct an MCJIT. But the MCJIT actually wants a RTDyldMemoryManager.
Consequently, the SectionMemoryManager, which is meant for MCJIT, derived
from the JITMemoryManager and then stubbed out a bunch of JITMemoryManager
methods that weren't relevant to the MCJIT.
This patch fixes the situation: it teaches the EngineBuilder that
RTDyldMemoryManager is a supertype of JITMemoryManager, and that it's
appropriate to pass a RTDyldMemoryManager instead of a JITMemoryManager if
we're using the MCJIT. This allows us to remove the stub methods from
SectionMemoryManager, and make SectionMemoryManager a direct subtype of
RTDyldMemoryManager.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181820 91177308-0d34-0410-b5e6-96231b3b80d8
MCJIT on Windows requires an explicit target triple with "-elf" appended to generate objects in ELF format. The common test framework was setting up this triple, but it wasn't passed to the C API in the test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181614 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds the necessary configuration bits and #ifdef's to set up
the JIT/MCJIT test cases for SystemZ. Like other recent targets, we do
fully support MCJIT, but do not support the old JIT at all. Set up the
lit config files accordingly, and disable old-JIT unit tests.
Patch by Richard Sandiford.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181207 91177308-0d34-0410-b5e6-96231b3b80d8
Several platforms need to disable all old-JIT unit tests, since they only
support the new MCJIT. This currently done via #ifdef'ing out those tests
in the ExecutionEngine/JIT/*.cpp files. As those #ifdef's have grown
historically, we now have a number of repeated directives which -in total-
cover nearly the whole file, but leave a couple of helper functions out.
When building the tests with clang itself, those helper functions now
cause spurious "unused function" warnings.
To fix those warnings, and also to remove the duplicate #ifdef conditions
and make it easier to disable the tests for a new target, this patch
consolidates the #ifdefs into a single one per file, which covers all
the tests including all helper routines.
Tested on PowerPC and SystemZ.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181200 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for matching 'ordered' and 'unordered' floating point min/max
constructs.
In LLVM we can express min/max functions as a combination of compare and select.
We have support for matching such constructs for integers but not for floating
point. In floating point math there is no total order because of the presence of
'NaN'. Therefore, we have to be careful to preserve the original fcmp semantics
when interpreting floating point compare select combinations as a minimum or
maximum function. The resulting 'ordered/unordered' floating point maximum
function has to select the same value as the select/fcmp combination it is based
on.
ordered_max(x,y) = max(x,y) iff x and y are not NaN, y otherwise
unordered_max(x,y) = max(x,y) iff x and y are not NaN, x otherwise
ordered_min(x,y) = min(x,y) iff x and y are not NaN, y otherwise
unordered_min(x,y) = min(x,y) iff x and y are not NaN, x otherwise
This matches the behavior of the underlying select(fcmp(olt/ult/.., L, R), L, R)
construct.
Any code using this predicate has to preserve this semantics.
A follow-up patch will use this to implement floating point min/max reductions
in the vectorizer.
radar://13723044
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181143 91177308-0d34-0410-b5e6-96231b3b80d8
CodeModel: It's now possible to create an MCJIT instance with any CodeModel you like. Previously it was only possible to
create an MCJIT that used CodeModel::JITDefault.
EnableFastISel: It's now possible to turn on the fast instruction selector.
The CodeModel option required some trickery. The problem is that previously, we were ensuring future binary compatibility in
the MCJITCompilerOptions by mandating that the user bzero's the options struct and passes the sizeof() that he saw; the
bindings then bzero the remaining bits. This works great but assumes that the bitwise zero equivalent of any field is a
sensible default value.
But this is not the case for LLVMCodeModel, or its internal equivalent, llvm::CodeModel::Model. In both of those, the default
for a JIT is CodeModel::JITDefault (or LLVMCodeModelJITDefault), which is not bitwise zero.
Hence this change introduces LLVMInitializeMCJITCompilerOptions(), which will initialize the user's options struct with
defaults. The user will use this in the same way that they would have previously used memset() or bzero(). MCJITCAPITest.cpp
illustrates the change, as does the comment in ExecutionEngine.h.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180893 91177308-0d34-0410-b5e6-96231b3b80d8
Re-submitting with fix for OCaml dependency problems (removing dependency on SectionMemoryManager when it isn't used).
Patch by Fili Pizlo
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180720 91177308-0d34-0410-b5e6-96231b3b80d8
That seems to interact poorly with the environ and _environ macros
defined in MSVC's <stdlib.h>.
Also remove the incorrect comment about _NSGetEnviron().
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180200 91177308-0d34-0410-b5e6-96231b3b80d8
This was r180041 and r180046, which was reverted in r180066.
Re-committing this should fix the dragonegg bootstrap, which I presume
needs LD_LIBRARY_PATH to be propagated to the child.
Tested on Linux, Windows, and Mac OS 10.6.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180099 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is http://llvm.org/PR15802. Backslashes preceding double quotes in
arguments must be escaped. The interesting bit is that all other
backslashes should *not* be escaped, because the un-escaping logic is
only triggered by the presence of a double quote character.
Reviewers: Bigcheese
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D705
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180035 91177308-0d34-0410-b5e6-96231b3b80d8
rather than checking if the source and destination have the same number of
arguments and copying the attributes over directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179169 91177308-0d34-0410-b5e6-96231b3b80d8
Looks like cmake on windows is not expanding ENABLE_EXPORTS to
-Wl,--export-all-symbols on mingw or cygwin, so add this back.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178730 91177308-0d34-0410-b5e6-96231b3b80d8
On freebsd this makes sure that symbols are exported on the binaries that need
them. The net result is that we should get symbols in the binaries that need
them on every platform.
On linux x86-64 this reduces the size of the bin directory from 262MB to 250MB.
Patch by Stephen Checkoway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178725 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 617330909f.
It broke the bots:
/home/clangbuild2/clang-ppc64-2/llvm.src/unittests/ADT/SmallVectorTest.cpp:150: PushPopTest
/home/clangbuild2/clang-ppc64-2/llvm.src/unittests/ADT/SmallVectorTest.cpp:118: Failure
Value of: v[i].getValue()
Actual: 0
Expected: value
Which is: 2
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178334 91177308-0d34-0410-b5e6-96231b3b80d8
This generalizes Optional to require less from the T type by using aligned
storage for backing & placement new/deleting the T into it when necessary.
Also includes unit tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175580 91177308-0d34-0410-b5e6-96231b3b80d8
PR15138 was opened because of a segfault in the Bitcode writer.
The actual issue ended up being a bug in APInt where calls to
APInt::getActiveWords returns a bogus value when the APInt value
is 0. This patch fixes the problem by ensuring that getActiveWords
returns 1 for 0 valued APInts.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174641 91177308-0d34-0410-b5e6-96231b3b80d8
reference to a pointer, so that it can handle the case where DataLayout
is not available and behave conservatively.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174024 91177308-0d34-0410-b5e6-96231b3b80d8
As a bonus I put in some extra checks to make sure that we are identifying the
machine word of various Mac OS X/iOS targets appropriately.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173994 91177308-0d34-0410-b5e6-96231b3b80d8
I got blamed on darwin11;
unittests/Support/ManagedStatic.cpp:35: error: 'pthread_attr_setstack' was not declared in this scope
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173355 91177308-0d34-0410-b5e6-96231b3b80d8
ErrorOr<void> represents an operation that returns nothing, but can still fail.
It should be used in cases where you need the aditional user data that ErrorOr
provides over error_code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173209 91177308-0d34-0410-b5e6-96231b3b80d8
A SparseMultiSet adds multiset behavior to SparseSet, while retaining SparseSet's desirable properties. Essentially, SparseMultiSet provides multiset behavior by storing its dense data in doubly linked lists that are inlined into the dense vector. This allows it to provide good data locality as well as vector-like constant-time clear() and fast constant time find(), insert(), and erase(). It also allows SparseMultiSet to have a builtin recycler rather than keeping SparseSet's behavior of always swapping upon removal, which allows it to preserve more iterators. It's often a better alternative to a SparseSet of a growable container or vector-of-vector.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173064 91177308-0d34-0410-b5e6-96231b3b80d8
In r143502, we renamed getHostTriple() to getDefaultTargetTriple()
as part of work to allow the user to supply a different default
target triple at configure time. This change also affected the JIT.
However, it is inappropriate to use the default target triple in the
JIT in most circumstances because this will not necessarily match
the current architecture used by the process, leading to illegal
instruction and other such errors at run time.
Introduce the getProcessTriple() function for use in the JIT and
its clients, and cause the JIT to use it. On architectures with a
single bitness, the host and process triples are identical. On other
architectures, the host triple represents the architecture of the
host CPU, while the process triple represents the architecture used
by the host CPU to interpret machine code within the current process.
For example, when executing 32-bit code on a 64-bit Linux machine,
the host triple may be 'x86_64-unknown-linux-gnu', while the process
triple may be 'i386-unknown-linux-gnu'.
This fixes JIT for the 32-on-64-bit (and vice versa) build on non-Apple
platforms.
Differential Revision: http://llvm-reviews.chandlerc.com/D254
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172627 91177308-0d34-0410-b5e6-96231b3b80d8
