[CMake] LLVMSupport should be responsible to provide system_libs.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201077 91177308-0d34-0410-b5e6-96231b3b80d8

Fix LLVM install rules to not set permissions on include/

The CMake install(DIRECTORY) command documents that it sets permissions
on directories it is asked to install.  Since the <prefix>/include
directory may not be exclusive to the LLVM installation, we should not
ask CMake to manage permissions of that directory for us.  Instead, give
only our own include/llvm and include/llvm-c subdirectories to the
install(DIRECTORY) command.

Fixes PR4500. Patch by Brad King.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201075 91177308-0d34-0410-b5e6-96231b3b80d8

[CMake] Introduce llvm_add_library().

  - MODULE;SHARED;STATIC
      STATIC by default w/o BUILD_SHARED_LIBS.
      SHARED by default w/  BUILD_SHARED_LIBS.
  - OUTPUT_NAME name
      Corresponds to OUTPUT_NAME in target properties.
  - DEPENDS targets...
      Same semantics as add_dependencies().
  - LINK_COMPONENTS components...
      Same as the variable LLVM_LINK_COMPONENTS.
  - LINK_LIBS lib_targets...
      Same semantics as target_link_libraries().
  - ADDITIONAL_HEADERS (implemented in LLVMProcessSources)
      May specify header files for IDE generators.

I suggest llvm_add_library() may be used for inter-project add_library stuff
and also suggest add_***_library() may be used project-specific.

Please be patient that llvm_add_library might be ambiguous against add_llvm_library.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201072 91177308-0d34-0410-b5e6-96231b3b80d8

[asan] support for FreeBSD, LLVM part. patch by Viktor Kutuzov

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201067 91177308-0d34-0410-b5e6-96231b3b80d8

AVX-512: Fixed extract_vector_elt for v16i1 and v8i1 vectors.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201066 91177308-0d34-0410-b5e6-96231b3b80d8

Recommit r201059 and r201060 with hopefully a fix for its original failure.

Original commits messages:

Add MRMXr/MRMXm form to X86 for use by instructions which treat the 'reg' field of modrm byte as a don't care value. Will allow for simplification of disassembler code.

Simplify a bunch of code by removing the need for the x86 disassembler table builder to know about extended opcodes. The modrm forms are sufficient to convey the information.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201065 91177308-0d34-0410-b5e6-96231b3b80d8

Revert r201059 and r201060.

r201059 appears to cause a crash in a bootstrapped build of clang. Craig
isn't available to look at it right now, so I'm reverting it while he
investigates.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201064 91177308-0d34-0410-b5e6-96231b3b80d8

[CMake] LLVMProcessSources.cmake: Prune add_file_dependencies to ${TABLEGEN_OUTPUT}.

I am sure it'd not be required any more.
In trunk, all of tablegen's users depend on ${TABLEGEN_OUTPUT} as not file dependency but inter-target dependency.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201063 91177308-0d34-0410-b5e6-96231b3b80d8

[CMake] Re-apply r200765, "Get rid of llvm_config() to expand dependencies."

CMake's target_link_libraries() will manage dependencies with Brad's LLVMConfig improvements.

Configuration time may be reduced by a few seconds.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201062 91177308-0d34-0410-b5e6-96231b3b80d8

[AArch64]Implement the copy of two FPR8 registers by using FMOVss of two FPR32 registers in copyPhysReg.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201061 91177308-0d34-0410-b5e6-96231b3b80d8

Simplify a bunch of code by removing the need for the x86 disassembler table builder to know about extended opcodes. The modrm forms are sufficient to convey the information.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201060 91177308-0d34-0410-b5e6-96231b3b80d8

Add MRMXr/MRMXm form to X86 for use by instructions which treat the 'reg' field of modrm byte as a don't care value. Will allow for simplification of disassembler code.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201059 91177308-0d34-0410-b5e6-96231b3b80d8

MCParser: add a single token lookahead

Some of the more complex directive and macro handling for GAS compatibility
requires lookahead.  Add a single token lookahead in the MCAsmLexer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201058 91177308-0d34-0410-b5e6-96231b3b80d8

Remove shell comment in the middle of a single-line command.

You can't put a comment in the middle of a command like this. This is
invalid shell syntax and breaks the build.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201057 91177308-0d34-0410-b5e6-96231b3b80d8

AsmParser: Simplify code with ArrayRef.

No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201055 91177308-0d34-0410-b5e6-96231b3b80d8

Whitespace.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201054 91177308-0d34-0410-b5e6-96231b3b80d8

Provide CMake package modules in install tree

Teach the Makefile build system to generate and install CMake modules
LLVMConfig.cmake and LLVMConfigVersion.cmake so that applications that
build with CMake can use 'find_package(LLVM)' even when LLVM is not
built with CMake.  These modules tell such applications about available
LLVM libraries and their dependencies.

Run llvm-config to generate the list of libraries and use the results of
llvm-build to generate the library dependencies.  Use sed to perform
substitutions in the LLVMConfig.cmake.in and LLVMConfigVersion.cmake.in
sources that our CMake build system uses.

Teach the Makefile build system to generate the LLVMExports.cmake file
with content similar to that produced by the CMake install(EXPORT)
command.  Extend llvm-build with an option to generate the library
dependencies fragment for this file.

Contributed by Brad King.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201053 91177308-0d34-0410-b5e6-96231b3b80d8

Add version, arch, system libs, and targets to Makefile.config

Teach autoconf/configure.ac to AC_SUBST several additional values in
Makefile.config to make them available to Makefile code.  These will
be useful to generate CMake package modules from the Makefile build.

Contributed by Brad King.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201052 91177308-0d34-0410-b5e6-96231b3b80d8

Load exported lib and exe targets from LLVMConfig

Teach each package configuration file to load the LLVMExports file for
its corresponding tree.  This will allow application CMake code to use
logical library and executable target names from LLVM as if they were in
our own build process (e.g. LLVMSupport).  CMake will have enough
information to propagate LLVM library link dependencies automatically
while configuring applications.

Contributed by Brad King.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201051 91177308-0d34-0410-b5e6-96231b3b80d8

Export lib and exe build target names from build tree

Record every logical target that we install with install(TARGETS) in a
global LLVM_EXPORTS property.  Then use the export(TARGETS) command to
provide a "LLVMExports.cmake" file that exports logical targets for
import into applications directly from our build tree.

The "LLVMExports.cmake" file is not meant for direct inclusion by
application code but should be included by "LLVMConfig.cmake" in a
future change.

Contributed by Brad King.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201050 91177308-0d34-0410-b5e6-96231b3b80d8

Export lib and exe build target names from install tree

Use the install(TARGETS) command EXPORT option for every library and
executable that we install with LLVM.  Then use the install(EXPORT)
command to provide a "LLVMExports.cmake" file that exports logical
targets for import into applications from our install tree.

The "LLVMExports.cmake" file is not meant for direct inclusion by
application code but should be included by "LLVMConfig.cmake" in a
future change.

Contributed by Brad King.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201049 91177308-0d34-0410-b5e6-96231b3b80d8

Provide LLVMConfig in both build and install tree

Create separate package configuration files "LLVMConfig.cmake" for the
LLVM build and install trees so that each can have information specific
to its tree.  Configure each with the corresponding include, lib, and
cmake directories.  Include the "LLVM-Config" API modules directly from
the configured cmake modules directory.

In the install tree, compute the installation prefix relative to the
file location.  In the build tree, provide information specific to the
build tree for use by tools like Clang that can build externally against
the LLVM build tree.  Prefix such values in "LLVM_BUILD_" and comment
them as such.

Contributed by Brad King.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201048 91177308-0d34-0410-b5e6-96231b3b80d8

Teach LLVMConfig to avoid modifying CMAKE_MODULE_PATH

Do not modify this value on the application's behalf and just ensure API
modules are always available next to the LLVMConfig module.  This is
already the case in the install tree so use file(COPY) to make it so in
the build tree.  Include the LLVM-Config API module from next to the
LLVMConfig location.

Contributed by Brad King.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201047 91177308-0d34-0410-b5e6-96231b3b80d8

De-duplicate references to share/llvm/cmake path

Use a LLVM_INSTALL_PACKAGE_DIR variable to hold the path and reference
it where necessary.

Contributed by Brad King.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201046 91177308-0d34-0410-b5e6-96231b3b80d8

AsmParser: Parse (and ignore) nested .macro definitions.

This enables a slightly odd feature of gas. The macro is defined when
the outermost macro is instantiated.

PR18599

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201045 91177308-0d34-0410-b5e6-96231b3b80d8

Use a consistent argument order in TargetLoweringObjectFile.

These methods normally call each other and it is really annoying if the
arguments are in different order. The more common rule was that the arguments
specific to call are first (GV, Encoding, Suffix) and the auxiliary objects
(Mang, TM) come after. This patch changes the exceptions.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201044 91177308-0d34-0410-b5e6-96231b3b80d8

Fix formatting introduced in r200941

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201043 91177308-0d34-0410-b5e6-96231b3b80d8

Remove unnecessary include.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201041 91177308-0d34-0410-b5e6-96231b3b80d8

Remove some unnecessary code. The conditions it was checking had already been ruled out by the caller.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201039 91177308-0d34-0410-b5e6-96231b3b80d8

tools: cast the right operand

Properly apply the fix intended by SVN r201032.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201036 91177308-0d34-0410-b5e6-96231b3b80d8

[docs] [tblgen] clarify that code fragments are just string literals

Fun fact: looking at the TableGen code (around TGParser.cpp:1166), the
only difference in handling is that adjacent regular string literals are
concatenated in the parser.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201035 91177308-0d34-0410-b5e6-96231b3b80d8

[docs] [tblgen] There is no "code" type.

Code fragments are just fancy string literals.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201034 91177308-0d34-0410-b5e6-96231b3b80d8

[docs] TableGen easter egg: Multiline string literals

They're called code fragments, but they are really multiline string
literals. Just spotted this usage in a patch by Aaron using "code
fragments" for holding documentation text. I remember someone bemoaning
the lack of multiline string literals in TableGen, so I'm explicitly
documenting that code fragments are multiline string literals.

Let it be known that any use case needing multiline string literals in
TableGen (such as descriptions of options, or whatnot) can use use
code fragments (instead of C-style string concatenation or exceedingly
long lines). E.g.

    class Bar<int n>;
    class Baz<int n>;
    class Doc<string desc> {
        string Desc = desc;
    }
    def Foo : Bar<1>, Baz<3>, Doc<[{
    This Foo is a Bar, and also a Baz. It can take 3 values:
        * Qux
        * Quux
        * Quuux
    }]>;

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201033 91177308-0d34-0410-b5e6-96231b3b80d8

tools: explicitly cast to avoid a warning

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201032 91177308-0d34-0410-b5e6-96231b3b80d8

tools: handle out-of-line personality 0 decoding

In some cases it is possible to have a personality 0 unwinding opcodes in the
extab (such as when .handlerdata is used in the assembly).  Simply decode the 3
opcodes for that case.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201030 91177308-0d34-0410-b5e6-96231b3b80d8

ARM: change attribute tests to use parsed form

This makes the tests more readable by using the -arm-attributes decoding support
in llvm-readobj since that is now available.  Change the invocation commands to
be similar to other test and use a more precise triple (the tests only require
ARM EABI support).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201029 91177308-0d34-0410-b5e6-96231b3b80d8

LoopVectorizer: Keep track of conditional store basic blocks

Before conditional store vectorization/unrolling we had only one
vectorized/unrolled basic block. After adding support for conditional store
vectorization this will not only be one block but multiple basic blocks. The
last block would have the back-edge. I updated the code to use a vector of basic
blocks instead of a single basic block and fixed the users to use the last entry
in this vector. But, I forgot to add the basic blocks to this vector!

Fixes PR18724.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201028 91177308-0d34-0410-b5e6-96231b3b80d8

Pass the Mangler by reference.

It is never null and it is not used in casts, so there is no reason to use a
pointer. This matches how we pass TM.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201025 91177308-0d34-0410-b5e6-96231b3b80d8

Add LLVM_OVERRIDE to a few declarations.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201022 91177308-0d34-0410-b5e6-96231b3b80d8

[Constant Hoisting] Fix insertion point for constant materialization.

The bitcast instruction during constant materialization was not placed correcly
in the presence of phi nodes. This commit fixes the insertion point to be in the
idom instead.

This fixes PR18768

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201009 91177308-0d34-0410-b5e6-96231b3b80d8

[Constant Hoisting] Don't update the use list while traversing it - DOH!

This fix first traverses the whole use list of the constant expression and
keeps track of the instructions that need to be updated. Then perform the
fixup afterwards.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201008 91177308-0d34-0410-b5e6-96231b3b80d8

Remove dead code.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201006 91177308-0d34-0410-b5e6-96231b3b80d8

Improve existing visualizers by:

- Properly displaying non null terminated StringRef.
- Auto expanding pointer types.
- Displaying real type names for PointerUnions.
- Using "size" and "capacity" across all containers.
- Simplifying code where possible.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201004 91177308-0d34-0410-b5e6-96231b3b80d8

 Comment cleanup. Don't repeat the function name in the comment.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201001 91177308-0d34-0410-b5e6-96231b3b80d8

Comment cleanup. Don't repeat the function name in the comment.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200999 91177308-0d34-0410-b5e6-96231b3b80d8

Remove training whitespace.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200998 91177308-0d34-0410-b5e6-96231b3b80d8

Always create a temporary symbol to use with the cfi frame.

This is a small simplification and a small step in fixing pr18743 since
private functions on MachO should be using a 'l' prefix.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200994 91177308-0d34-0410-b5e6-96231b3b80d8

Use FileCheck variables to simplify this test.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200992 91177308-0d34-0410-b5e6-96231b3b80d8

Fix Darwin bots from EHABI change

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200990 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Add failing test for 3 x i64 vectors.

Stores of <4 x i64> do work (although they do expand to 4 stores
instead of 2), but 3 x i64 vectors fail to select.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200989 91177308-0d34-0410-b5e6-96231b3b80d8

Remove -arm-disable-ehabi option

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200988 91177308-0d34-0410-b5e6-96231b3b80d8

Don't internalize linkonce_odr non constant variables.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200983 91177308-0d34-0410-b5e6-96231b3b80d8

Fix an invalid check for duplicate option categories.

An intermediate solution until the problems with analyzer plugins linking with
llvm/Support and causing assertions due to duplicate GeneralCategory are solved.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200981 91177308-0d34-0410-b5e6-96231b3b80d8

[mips] Forbid the use of registers t6, t7 and t8 if the target is NaCl.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200978 91177308-0d34-0410-b5e6-96231b3b80d8

Fix a bug with .weak_def_can_be_hidden: Mutable variables cannot use it.

Thanks to John McCall for noticing it.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200977 91177308-0d34-0410-b5e6-96231b3b80d8

Refactor logic into a function predicate.

No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200976 91177308-0d34-0410-b5e6-96231b3b80d8

Try to unbreak the mingw32 build.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200973 91177308-0d34-0410-b5e6-96231b3b80d8

LLVM-1163: AAPCS-VFP violation when CPRC allocated to stack

According to the AAPCS, when a CPRC is allocated to the stack, all other
VFP registers should be marked as unavailable.

I have also modified the rules for allocating non-CPRCs to the stack, to make
it more explicit that all GPRs must be made unavailable. I cannot think of a
case where the old version would produce incorrect answers, so there is no test
for this.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200970 91177308-0d34-0410-b5e6-96231b3b80d8

Changed comment.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200969 91177308-0d34-0410-b5e6-96231b3b80d8

[Sparc] Add support for parsing synthetic instruction 'mov'.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200965 91177308-0d34-0410-b5e6-96231b3b80d8

[Sparc] Emit correct encoding for atomic instructions. Also, add support for parsing CAS instructions to test the CAS encoding.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200963 91177308-0d34-0410-b5e6-96231b3b80d8

[Sparc] Emit relocations for Thread Local Storage (TLS) when integrated assembler is used.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200962 91177308-0d34-0410-b5e6-96231b3b80d8

[Sparc] Emit correct relocations for PIC code when integrated assembler is used.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200961 91177308-0d34-0410-b5e6-96231b3b80d8

[Sparc] Use SparcMCExpr::VariantKind itself as MachineOperand's target flags.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200960 91177308-0d34-0410-b5e6-96231b3b80d8

PGO branch weight: fix PR18752.

Fix a bug triggered in IfConverterTriangle when CvtBB has multiple predecessors
by getting the weights before removing a successor.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200958 91177308-0d34-0410-b5e6-96231b3b80d8

X86: Resolve a long standing FIXME and properly isel pextr[bw].

Generalize the AArch64 .td nodes for AssertZext and AssertSext. Use
them to match the relevant pextr store instructions.

The test widen_load-2.ll requires a slight change because with the
stores gone, the remaining instructions are scheduled in a different
order.

Add test cases for SSE4 and AVX variants.

Resolves rdar://13414672.

Patch by Adam Nemet <anemet@apple.com>.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200957 91177308-0d34-0410-b5e6-96231b3b80d8

Convert test to FileCheck.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200955 91177308-0d34-0410-b5e6-96231b3b80d8

[CodeGenPrepare] Move away sign extensions that get in the way of addressing
mode.

Basically the idea is to transform code like this:
%idx = add nsw i32 %a, 1
%sextidx = sext i32 %idx to i64
%gep = gep i8* %myArray, i64 %sextidx
load i8* %gep

Into:
%sexta = sext i32 %a to i64
%idx = add nsw i64 %sexta, 1
%gep = gep i8* %myArray, i64 %idx
load i8* %gep

That way the computation can be folded into the addressing mode.

This transformation is done as part of the addressing mode matcher.
If the matching fails (not profitable, addressing mode not legal, etc.), the
matcher will revert the related promotions.

<rdar://problem/15519855>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200947 91177308-0d34-0410-b5e6-96231b3b80d8

Track register pressure a bit more carefully (weird corner case).

This solves a problem where a def machine operand has no uses but has
not been marked dead. In this case, the initial RP analysis was being
extra precise and determining from LiveIntervals the the register was
actually dead. This caused us to omit the register from the RP
tracker's block live out. That's all good, but the per-instruction
summary still accounted for it as a valid def. This could cause an
assertion in the tracker later when we underflow pressure.

This is from a bug report on an out-of-tree target. It is not
reproducible on well-behaved targets. I'm just making an obvious fix
without unit test.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200941 91177308-0d34-0410-b5e6-96231b3b80d8

Revert r200095 and r200152. It turns out when compiling with -arch armv7 -mcpu=cortex-m3, the triple would still set iOS as the OS so the hack is still needed. rdar://15984891

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200937 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Add a MUBUF store pattern for Reg+Imm offsets

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200935 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Add a MUBUF store pattern for Imm offsets

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200934 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Add a MUBUF load pattern for Reg+Imm offsets

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200933 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Use immediates offsets for SMRD instructions whenever possible

There was a problem with the old pattern, so we were copying some
larger immediates into registers when we could have been encoding
them in the instruction.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200932 91177308-0d34-0410-b5e6-96231b3b80d8

Remove const_cast for STI when parsing inline asm

In a previous commit (r199818) we added a const_cast to an existing
subtarget info instead of creating a new one so that we could reuse
it when creating the TargetAsmParser for parsing inline assembly.
This cast was necessary because we needed to reuse the existing STI
to avoid generating incorrect code when the inline asm contained
mode-switching directives (e.g. .code 16).

The root cause of the failure was that there was an implicit sharing
of the STI between the parser and the MCCodeEmitter. To fix a
different but related issue, we now explicitly pass the STI to the
MCCodeEmitter (see commits r200345-r200351).

The const_cast is no longer necessary and we can now create a fresh
STI for the inline asm parser to use.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200929 91177308-0d34-0410-b5e6-96231b3b80d8

X86: add costs for 64-bit vector ext/trunc & rebalance

The most important part of this is probably adding any cost at all for
operations like zext <8 x i8> to <8 x i32>. Before they were being
recorded as extremely costly (24, I believe) which made LLVM fall back
on a 4-wide vectorisation of a loop.

It also rebalances the values for sext, zext and trunc. Lacking any
other sane metric that might work across CPU microarchitectures I went
for instructions. This seems to be in reasonable accord with the rest
of the table (sitofp, ...) though no doubt at least one value is
sub-optimal for some bizarre reason.

Finally, separate AVX and AVX2 values are provided where appropriate.
The CodeGen is quite different in many cases.

rdar://problem/15981990

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200928 91177308-0d34-0410-b5e6-96231b3b80d8

Add a -suppress-warnings option to bitcode linking.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200927 91177308-0d34-0410-b5e6-96231b3b80d8

Yet another patch to reduce compile time for small programs:

The aim in this patch is to reduce work that VirtRegRewriter needs to do when
telling MachineRegisterInfo which physregs are in use. Up until now
VirtRegRewriter::rewrite has been doing rewriting and populating def info and
then proceeding to set whether a physreg is used based this info for every
physreg that the target provides. This can be expensive when a target has an
unusually high number of supported physregs, and is a noticeable chunk of
compile time for small programs on such targets.

So to reduce compile time, this patch simply adds the use of a SparseSet to the
rewrite function that is used to flag each physreg that is encountered in a
MachineFunction. Afterward, rather than iterating over the set of all physregs
for a given target to set the physregs used in MachineRegisterInfo, the new way
is to iterate over the set of physregs that were actually encountered and set
in the SparseSet. This improves compile time because the existing rewrite
function was iterating over all MachineOperands already, and because the
iterations afterward to setPhysRegUsed is reduced by use of the SparseSet data.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200919 91177308-0d34-0410-b5e6-96231b3b80d8

X86: deduplicate V[SZ]EXT_MOVL and V[SZ]EXT nodes

I believe VZEXT_MOVL means "zero all vector elements except the first" (and
should have identical input & output types) whereas VZEXT means "zero extend
each element of a vector (discarding higher elements if necessary)".

For example:
    (v4i32 (vzext (v16i8 ...)))

should zero extend the low 4 bytes of the incoming vector to 32-bits,
discarding higher bytes.

However, somewhere in the past, these two concepts had become confused, even
leading to a nonsensical VSEXT_MOVL.

This re-merges the nodes where appropriate (all VSEXT_MOVL -> VSEXT, VZEXT_MOVL
-> VZEXT when it's an actual extension).

rdar://problem/15981990

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200918 91177308-0d34-0410-b5e6-96231b3b80d8

The following patch' purpose is to reduce compile time for compilation of small
programs on targets with large register files. The root of the compile time
overhead was in the use of llvm::SmallVector to hold PhysRegEntries, which
resulted in slow-down from calling llvm::SmallVector::assign(N, 0). In contrast
std::vector uses the faster __platform_bzero to zero out primitive buffers when
assign is called, while SmallVector uses an iterator.

The fix for this was simply to replace the SmallVector with a dynamically
allocated buffer and to initialize or reinitialize the buffer based on the
total registers that the target architecture requires. The changes support
cases where a pass manager may be reused for different targets, and note that
the PhysRegEntries is allocated using calloc mainly for good for, and also to
quite tools like Valgrind (see comments for more info on this).

There is an rdar to track the fact that SmallVector doesn't have platform
specific speedup optimizations inside of it for things like this, and I'll
create a bugzilla entry at some point soon as well.

TL;DR: This fix replaces the expensive llvm::SmallVector<unsigned
char>::assign(N, 0) with a call to calloc for N bytes which is much faster
because SmallVector's assign uses iterators.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200917 91177308-0d34-0410-b5e6-96231b3b80d8

This small change reduces compile time for small programs on targets that have
large register files. The omission of Queries.clear() is perfectly safe because
LiveIntervalUnion::Query doesn't contain any data that needs freeing and
because LiveRegMatrix::runOnFunction happens to reset the OwningArrayPtr
holding Queries every time it is run, so there's no need to zero out the
queries either. Not having to do this for very large numbers of physregs
is a noticeable constant cost reduction in compilation of small programs.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200913 91177308-0d34-0410-b5e6-96231b3b80d8

A memcpy out of an fresh alloca is a no-op, delete it. Patch by Patrick Walton!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200907 91177308-0d34-0410-b5e6-96231b3b80d8

Delete all of the CodeGenInstructions from CodeGenTarget destructor.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200906 91177308-0d34-0410-b5e6-96231b3b80d8

[PM] Fix horrible typos that somehow didn't cause a failure in a C++11
build but spectacularly changed behavior of the C++98 build. =]

This shows my one problem with not having unittests -- basic API
expectations aren't well exercised by the integration tests because they
*happen* to not come up, even though they might later. I'll probably add
a basic unittest to complement the integration testing later, but
I wanted to revive the bots.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200905 91177308-0d34-0410-b5e6-96231b3b80d8

[PM] Add a new "lazy" call graph analysis pass for the new pass manager.

The primary motivation for this pass is to separate the call graph
analysis used by the new pass manager's CGSCC pass management from the
existing call graph analysis pass. That analysis pass is (somewhat
unfortunately) over-constrained by the existing CallGraphSCCPassManager
requirements. Those requirements make it *really* hard to cleanly layer
the needed functionality for the new pass manager on top of the existing
analysis.

However, there are also a bunch of things that the pass manager would
specifically benefit from doing differently from the existing call graph
analysis, and this new implementation tries to address several of them:

- Be lazy about scanning function definitions. The existing pass eagerly
  scans the entire module to build the initial graph. This new pass is
  significantly more lazy, and I plan to push this even further to
  maximize locality during CGSCC walks.
- Don't use a single synthetic node to partition functions with an
  indirect call from functions whose address is taken. This node creates
  a huge choke-point which would preclude good parallelization across
  the fanout of the SCC graph when we got to the point of looking at
  such changes to LLVM.
- Use a memory dense and lightweight representation of the call graph
  rather than value handles and tracking call instructions. This will
  require explicit update calls instead of some updates working
  transparently, but should end up being significantly more efficient.
  The explicit update calls ended up being needed in many cases for the
  existing call graph so we don't really lose anything.
- Doesn't explicitly model SCCs and thus doesn't provide an "identity"
  for an SCC which is stable across updates. This is essential for the
  new pass manager to work correctly.
- Only form the graph necessary for traversing all of the functions in
  an SCC friendly order. This is a much simpler graph structure and
  should be more memory dense. It does limit the ways in which it is
  appropriate to use this analysis. I wish I had a better name than
  "call graph". I've commented extensively this aspect.

This is still very much a WIP, in fact it is really just the initial
bits. But it is about the fourth version of the initial bits that I've
implemented with each of the others running into really frustrating
problms. This looks like it will actually work and I'd like to split the
actual complexity across commits for the sake of my reviewers. =] The
rest of the implementation along with lots of wiring will follow
somewhat more rapidly now that there is a good path forward.

Naturally, this doesn't impact any of the existing optimizer. This code
is specific to the new pass manager.

A bunch of thanks are deserved for the various folks that have helped
with the design of this, especially Nick Lewycky who actually sat with
me to go through the fundamentals of the final version here.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200903 91177308-0d34-0410-b5e6-96231b3b80d8

[PM] Back out one hunk of the patch in r200901 that was *supposed* to go
in my next patch. Sorry for the breakage.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200902 91177308-0d34-0410-b5e6-96231b3b80d8

[PM] Wire up the analysis managers in the opt driver. This isn't really
necessary until we add analyses to the driver, but I have such an
analysis ready and wanted to split this out. This is actually exercised
by the existing tests of the new pass manager as the analysis managers
are cross-checked and validated by the function and module managers.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200901 91177308-0d34-0410-b5e6-96231b3b80d8

[DAG] Don't pull the binary operation though the shift if the operands have opaque constants.

During DAGCombine visitShiftByConstant assumes that certain binary operations
with only constant operands can always be folded successfully. This is no longer
true when the constant is opaque. This commit fixes visitShiftByConstant by not
performing the optimization for opaque constants. Otherwise we would end up in
an infinite DAGCombine loop.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200900 91177308-0d34-0410-b5e6-96231b3b80d8

Set default of inlinecold-threshold to 225.

225 is the default value of inline-threshold. This change will make sure
we have the same inlining behavior as prior to r200886.

As Chandler points out, even though we don't have code in our testing
suite that uses cold attribute, there are larger applications that do
use cold attribute.

r200886 + this commit intend to keep the same behavior as prior to r200886.
We can later on tune the inlinecold-threshold.

The main purpose of r200886 is to help performance of instrumentation based
PGO before we actually hook up inliner with analysis passes such as BPI and BFI.
For instrumentation based PGO, we try to increase inlining of hot functions and
reduce inlining of cold functions by setting inlinecold-threshold.

Another option suggested by Chandler is to use a boolean flag that controls
if we should use OptSizeThreshold for cold functions. The default value
of the boolean flag should not change the current behavior. But it gives us
less freedom in controlling inlining of cold functions.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200898 91177308-0d34-0410-b5e6-96231b3b80d8

Update the X86 assembler for .intel_syntax to accept
the << and >> bitwise operators.

rdar://15975725

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200896 91177308-0d34-0410-b5e6-96231b3b80d8

don't set HasReliableSymbolDifference for ELF.

It is only used in MachObjectWriter.cpp. Another leftover from early days
of ELF in MC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200895 91177308-0d34-0410-b5e6-96231b3b80d8

doesSectionRequireSymbols is meaningless on ELF, remove.

This is a nop. doesSectionRequireSymbols is only used from
isSymbolLinkerVisible. isSymbolLinkerVisible only use from ELF was in

if (!Asm.isSymbolLinkerVisible(Symbol) && !Symbol.isUndefined())
  return false;

if (Symbol.isTemporary())
  return false;

If the symbol is a temporary this code returns false and it is irrelevant if
we take the first if or not. If the symbol is not a temporary,
Asm.isSymbolLinkerVisible returns true without ever calling
doesSectionRequireSymbols.

This was an horrible leftover from when support for ELF was first added.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200894 91177308-0d34-0410-b5e6-96231b3b80d8

Disable most IR-level transform passes on functions marked 'optnone'.
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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200892 91177308-0d34-0410-b5e6-96231b3b80d8

Just returning false is the default.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200890 91177308-0d34-0410-b5e6-96231b3b80d8

Pass address space to allowsUnalignedMemoryAccesses

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200888 91177308-0d34-0410-b5e6-96231b3b80d8

Add address space argument to allowsUnalignedMemoryAccess.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200887 91177308-0d34-0410-b5e6-96231b3b80d8

Inliner uses a smaller inline threshold for callees with cold attribute.

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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200886 91177308-0d34-0410-b5e6-96231b3b80d8

Fix layering StringRef copy using BumpPtrAllocator.

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

[RegAlloc] Add a last chance recoloring mechanism when everything else failed to
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

[PM] Don't require analysis results to be const in the new pass manager.

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