This is the first incremental patch to implement this feature. It adds no
functionality to LLVM but setup up the information needed from targets in
order to implement the optimization correctly. Each target needs to specify
the maximum number of store operations for conversion of the llvm.memset,
llvm.memcpy, and llvm.memmove intrinsics into a sequence of store operations.
The limit needs to be chosen at the threshold of performance for such an
optimization (generally smallish). The target also needs to specify whether
the target can support unaligned stores for multi-byte store operations.
This helps ensure the optimization doesn't generate code that will trap on
an alignment errors.
More patches to follow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22468 91177308-0d34-0410-b5e6-96231b3b80d8
for the command line options. This helps with situations where the executable
name sought is too generic and a more meaningful name needs to be used for
the command line options. It also helps satisfy picky project leaders.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22461 91177308-0d34-0410-b5e6-96231b3b80d8
* FIND_STD_PROGRAM will find a program in the path or using --with options
and verify that the path/bin/program is executable. Also allows checking
for include files and libraries. If found, USE_PROGRAM is set, otherwise
its not set. Also sets PROGRAM_BIN (bin directory), and PROGRAM_DIR (top
level directory). If headers are found, sets PROGRAM_INC. If libraries
are found, sets PROGRAM_LIB.
* CHECK_PROGRAM_SANITY can be used to run a program with some option that
only produces information output and requires no input. If the output
matches a regular expression, the program passes the sanity check.
Otherwise, an error occurs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22458 91177308-0d34-0410-b5e6-96231b3b80d8
vector that represents the .o file at once, build up a vector for each
section of the .o file. This is needed because the .o file writer needs
to be able to switch between sections as it emits them (e.g. switch
between the .text section and the .rel section when emitting code).
This patch has no functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22453 91177308-0d34-0410-b5e6-96231b3b80d8
SelectionDAGLegalize::ExpandLegalUINT_TO_FP method.
Add a new method, PromoteLegalUINT_TO_FP, which allows targets to request
that UINT_TO_FP operations be promoted to a larger input type. This is
useful for targets that have some UINT_TO_FP or SINT_TO_FP operations but
not all of them (like X86).
The same should be done with SINT_TO_FP, but this patch does not do that
yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22447 91177308-0d34-0410-b5e6-96231b3b80d8
printed as part of the opcode. This allows something like
cmp${cc}ss in the x86 backed to be printed as cmpltss, cmpless, etc.
depending on what the value of $cc is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22439 91177308-0d34-0410-b5e6-96231b3b80d8
Add parenthesis around the value being negated; that way, if the value
begins with a minus sign (e.g. negative integer), we won't generate a
C predecrement operator by mistake.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22437 91177308-0d34-0410-b5e6-96231b3b80d8
we actually get the path and not $GRAPHVIZ as the value.
* Add a #define for the gv program (HAVE_GV) and its value LLVM_PATH_GV.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22433 91177308-0d34-0410-b5e6-96231b3b80d8
GRAPHVIZ will contain the path to the program if its found (or "echo Graphviz"
if not) and the #define HAVE_GRAPHVIZ will be defined if its found.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22424 91177308-0d34-0410-b5e6-96231b3b80d8
It is not safe to call LegalizeOp on something that has already been legalized.
Instead, just force another iteration of legalization.
This could affect all platforms but X86, as this codepath is dynamically
dead on X86 (ISD::MEMSET and friends are legal).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22419 91177308-0d34-0410-b5e6-96231b3b80d8
JIT can run against a multi-threaded program without getting its data
structures messed up. Also had to add the examples directory to the path
for the tests so that ParallelJIT can be found.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22415 91177308-0d34-0410-b5e6-96231b3b80d8
Add an example program that utilizes multiple threads in the JIT to process
work. This was used by Evan Jones as the original test case for ensuring
that the ExecutionEngine was thread safe.
Original source by Evan Jones (adapted from other LLVM JIT examples) and
made LLVM style compliant by Reid Spencer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22411 91177308-0d34-0410-b5e6-96231b3b80d8
This patch completes the changes for making lli thread-safe. Here's the list
of changes:
* The Support/ThreadSupport* files were removed and replaced with the
MutexGuard.h file since all ThreadSupport* declared was a Mutex Guard.
The implementation of MutexGuard.h is now based on sys::Mutex which hides
its implementation and makes it unnecessary to have the -NoSupport.h and
-PThreads.h versions of ThreadSupport.
* All places in ExecutionEngine that previously referred to "Mutex" now
refer to sys::Mutex
* All places in ExecutionEngine that previously referred to "MutexLocker"
now refer to MutexGuard (this is frivolous but I believe the technically
correct name for such a class is "Guard" not a "Locker").
These changes passed all of llvm-test. All we need now are some test cases
that actually use multiple threads.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22404 91177308-0d34-0410-b5e6-96231b3b80d8
