Now to copy a string into a BumpPtrAllocator and get a StringRef to the copy:
StringRef myCopy = myStr.copy(myAllocator);
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200885 91177308-0d34-0410-b5e6-96231b3b80d8
find a register.
The idea is to choose a color for the variable that cannot be allocated and
recolor its interferences around. Unlike the current register allocation scheme,
it is allowed to change the color of an already assigned (but maybe not
splittable or spillable) live interval while propagating this change to its
neighbors.
In other word, there are two things that may help finding an available color:
- Already assigned variables (RS_Done) can be recolored to different color.
- The recoloring allows to catch solutions that needs to touch more that just
the neighbors of the current allocated variable.
E.g.,
vA can use {R1, R2 }
vB can use { R2, R3}
vC can use {R1 }
Where vA, vB, and vC cannot be split anymore (they are reloads for instance) and
they all interfere.
vA is assigned R1
vB is assigned R2
vC tries to evict vA but vA is already done.
=> Regular register allocation heuristic fails.
Last chance recoloring kicks in:
vC does as if vA was evicted => vC uses R1.
vC is marked as fixed.
vA needs to find a color.
None are available.
vA cannot evict vC: vC is a fixed virtual register now.
vA does as if vB was evicted => vA uses R2.
vB needs to find a color.
R3 is available.
Recoloring => vC = R1, vA = R2, vB = R3.
<rdar://problem/15947839>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200883 91177308-0d34-0410-b5e6-96231b3b80d8
I think this was just over-eagerness on my part. The analysis results
need to often be non-const because they need to (in some cases at least)
be updated by the transformation pass in order to remain correct. It
also makes lazy analyses (a common case) needlessly annoying to write in
order to make their entire state mutable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200881 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200853 91177308-0d34-0410-b5e6-96231b3b80d8
Small code model (and default reloc model) set Reloc::PIC_ in this test,
and PIC is not yet supported in MCJIT for MIPS.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200852 91177308-0d34-0410-b5e6-96231b3b80d8
In Thumb1 mode, bl instruction might be selected for branches between
basic blocks in the function if the offset is greater than 2KB.
However, this might cause SEGV because the destination symbol
is not marked as thumb function and the execution mode will be reset
to ARM mode.
Since we are sure that these symbols are in the same data fragment, we
can simply resolve these local symbols, and don't emit any relocation
information for this bl instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200842 91177308-0d34-0410-b5e6-96231b3b80d8
It is not clear how much we should try to expose in getFlags. For example,
should there be a SF_Object and a SF_Text?
But for information that is already being exposed, we may as well use it in
llvm-nm.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200820 91177308-0d34-0410-b5e6-96231b3b80d8
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]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200819 91177308-0d34-0410-b5e6-96231b3b80d8
CMake won't expand the dependency graph for us if the dependencies are in
another project, which leads to link errors in the standalone build.
This is a refinement of r200765.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200812 91177308-0d34-0410-b5e6-96231b3b80d8
r200744 moved this into cmake/config-ix.cmake, so that it would happen very
early in the build process. However, standalone builds of Clang and other
external projects never include this file (which is correct).
Now, -stdlib=libc++ and the LLVM_COMPILER_IS_GCC_COMPATIBLE option are
both set in a new include file, HandleLLVMStdlib, which is included by
both config-ix.cmake and HandleLLVMOptions.cmake. This preserves existing
behavior for projects relying on HandleLLVMOptions and still does the
right thing for builds of LLVM itself.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200811 91177308-0d34-0410-b5e6-96231b3b80d8
In file included from ../unittests/Support/ProcessTest.cpp:11:
../utils/unittest/googletest/include/gtest/gtest.h:1448:28: warning: comparison of integers of different signs: 'const unsigned int' and 'const int' [-Wsign-compare]
GTEST_IMPL_CMP_HELPER_(NE, !=);
~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
../utils/unittest/googletest/include/gtest/gtest.h:1433:12: note: expanded from macro 'GTEST_IMPL_CMP_HELPER_'
if (val1 op val2) {\
^
../unittests/Support/ProcessTest.cpp:46:3: note: in instantiation of function template specialization 'testing::internal::CmpHelperNE<unsigned int, int>' requested here
EXPECT_NE((r1 | r2), 0);
^
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200801 91177308-0d34-0410-b5e6-96231b3b80d8
Commuting the 231 and 132 variants would swap addends and
multiplicands/multipliers, which isn't valid.
I'm still trying to reduce a decent test case for this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200792 91177308-0d34-0410-b5e6-96231b3b80d8
No functional change. Updated loops from:
for (I = scc_begin(), E = scc_end(); I != E; ++I)
to:
for (I = scc_begin(); !I.isAtEnd(); ++I)
for teh win.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200789 91177308-0d34-0410-b5e6-96231b3b80d8
This patch fixes the ldr-pseudo implementation to work when used in
inline assembly. The fix is to move arm assembler constant pools
from the ARMAsmParser class to the ARMTargetStreamer class.
Previously we kept the assembler generated constant pools in the
ARMAsmParser object. This does not work for inline assembly because
a new parser object is created for each blob of inline assembly.
This patch moves the constant pools to the ARMTargetStreamer class
so that the constant pool will remain alive for the entire code
generation process.
An ARMTargetStreamer class is now required for the arm backend.
There was no existing implementation for MachO, only Asm and ELF.
Instead of creating an empty MachO subclass, we decided to make the
ARMTargetStreamer a non-abstract class and provide default
(llvm_unreachable) implementations for the non constant-pool related
methods.
Differential Revision: http://llvm-reviews.chandlerc.com/D2638
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200777 91177308-0d34-0410-b5e6-96231b3b80d8
There is no lit test for this, because it would be too big and
complicated, but it does fix a crash in the Arithm/Absdiff.* OpenCV test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200775 91177308-0d34-0410-b5e6-96231b3b80d8
The OpenCL specs say: "The vector versions of the math functions operate
component-wise. The description is per-component."
Patch by: Jan Vesely
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200773 91177308-0d34-0410-b5e6-96231b3b80d8
There was an extremely confusing proliferation of LLVM intrinsics to implement
the vacge & vacgt instructions. This combines them all into two polymorphic
intrinsics, shared across both backends.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200768 91177308-0d34-0410-b5e6-96231b3b80d8
CMake's target_link_libraries() will manage dependencies.
Configuration time may be reduced by a few seconds.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200765 91177308-0d34-0410-b5e6-96231b3b80d8
