Ideally only those transform passes that run at -O0 remain enabled,
in reality we get as close as we reasonably can.
Passes are responsible for disabling themselves, it's not the job of
the pass manager to do it for them.

llvm-svn: 200892

llvm-svn: 200890

llvm-svn: 200888

On R600, some address spaces have more strict alignment
requirements than others.

llvm-svn: 200887

Added command line option inlinecold-threshold to set threshold for inlining
functions with cold attribute. Listen to the cold attribute when it would
decrease the inline threshold.

llvm-svn: 200886

Now to copy a string into a BumpPtrAllocator and get a StringRef to the copy:

   StringRef myCopy = myStr.copy(myAllocator);
   

llvm-svn: 200885

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>

llvm-svn: 200883

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.

llvm-svn: 200881

Clang itself was not using this. The only way to access it was via llc.

llvm-svn: 200862

This reverts commit r200853.

It was causing clang/Analysis/checker-plugins.c to crash.

llvm-svn: 200858

This patch adds NaCl target for Mips. It also forbids indexed loads and
stores if the target is NaCl.

Patch by Sasa Stankovic.

Differential Revision: http://llvm-reviews.chandlerc.com/D2690

llvm-svn: 200855

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

Small code model (and default reloc model) set Reloc::PIC_ in this test,
and PIC is not yet supported in MCJIT for MIPS.

llvm-svn: 200852

llvm-svn: 200849

llvm-svn: 200843

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.

llvm-svn: 200842

llvm-svn: 200837

Fixes opencl-example if_* tests with radeonsi.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74469



Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 200830

llvm-svn: 200829

Get rid of a vector copy by just making a pointer out of the reference returned by getInstructionsByEnumValue instead of assigning it to a new vector.

llvm-svn: 200828

llvm-svn: 200827

This fixes PR18554.

Reviewers: Renato Golin, Keith Walker
llvm-svn: 200826

llvm-svn: 200825

Move matching for x86 BMI BLSI/BLSMSK/BLSR instructions to isel patterns instead of DAG combine. This weakens the ability to fold loads with them because we aren't able to match patterns that load the same thing twice. But maybe we should fix that if we care. The peephole optimizer will be able to fold some loads in its absense.

llvm-svn: 200824

Added VPTESTNM instruction.
Added a pattern to vselect (lit tests will follow).

llvm-svn: 200823

llvm-svn: 200821

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.

llvm-svn: 200820

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

llvm-svn: 200818

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.

llvm-svn: 200812

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.

llvm-svn: 200811

llvm-svn: 200808

llvm-svn: 200807

llvm-svn: 200806

llvm-svn: 200803

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);
  ^

llvm-svn: 200801

llvm-svn: 200800

llvm-svn: 200796

For the odd case of platforms with exp2 available but not ldexp.

llvm-svn: 200795

This should fix the build against old versions of libedit.

llvm-svn: 200794