This function adds an extra path argument to lto_module_create_from_memory.
The path argument will be passed to makeBuffer to make sure the MemoryBuffer
has a name and the created module has a module identifier.
This is mainly for emitting warning messages from the linker. When we emit
warning message on a module, we can use the module identifier.
rdar://15985737
llvm-svn: 201114
A const ObjectFile needs to be able to provide its name. For an IRObjectFile,
that means being able to call the mangler. Since each IRObjectFile can have
a different mangling, it is natural for them to contain a Mangler which is
therefore also const.
llvm-svn: 201113
The crux of the issue is that LCSSA doesn't preserve stateful alias
analyses. Before r200067, LICM didn't cause LCSSA to run in the LTO pass
manager, where LICM runs essentially without any of the other loop
passes. As a consequence the globalmodref-aa pass run before that loop
pass manager was able to survive the loop pass manager and be used by
DSE to eliminate stores in the function called from the loop body in
Adobe-C++/loop_unroll (and similar patterns in other benchmarks).
When LICM was taught to preserve LCSSA it had to require it as well.
This caused it to be run in the loop pass manager and because it did not
preserve AA, the stateful AA was lost. Most of LLVM's AA isn't stateful
and so this didn't manifest in most cases. Also, in most cases LCSSA was
already running, and so there was no interesting change.
The real kicker is that LCSSA by its definition (injecting PHI nodes
only) trivially preserves AA! All we need to do is mark it, and then
everything goes back to working as intended. It probably was blocking
some other weird cases of stateful AA but the only one I have is
a 1000-line IR test case from loop_unroll, so I don't really have a good
test case here.
Hopefully this fixes the regressions on performance that have been seen
since that revision.
llvm-svn: 201104
DS instructions that access local memory can only uses addresses that
are less than or equal to the value of M0. When M0 is uninitialized,
then we experience undefined behavior.
This patch also changes the behavior to emit S_WQM_B64 on pixel shaders
no matter what kind of DS instruction is used.
llvm-svn: 201097
This doesn't change any functionality, since we only have two shader
types (compute and pixel) that use local memory. We're just changing
the logic to match the documentation.
llvm-svn: 201096
Similarly to the vshrn instructions, these are simple zext/sext + trunc
operations. Using normal LLVM IR should allow for better code, and more sharing
with the AArch64 backend.
llvm-svn: 201093
For A- and R-class processors, r12 is not normally callee-saved, but is for
interrupt handlers. See AAPCS, 5.3.1.1, "Use of IP by the linker".
llvm-svn: 201089
vshrn is just the combination of a right shift and a truncate (and the limits
on the immediate value actually mean the signedness of the shift doesn't
matter). Using that representation allows us to get rid of an ARM-specific
intrinsic, share more code with AArch64 and hopefully get better code out of
the mid-end optimisers.
llvm-svn: 201085
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.
llvm-svn: 201075
- 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.
llvm-svn: 201072
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.
llvm-svn: 201065
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.
llvm-svn: 201064
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.
llvm-svn: 201063
CMake's target_link_libraries() will manage dependencies with Brad's LLVMConfig improvements.
Configuration time may be reduced by a few seconds.
llvm-svn: 201062
Some of the more complex directive and macro handling for GAS compatibility
requires lookahead. Add a single token lookahead in the MCAsmLexer.
llvm-svn: 201058
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.
llvm-svn: 201053
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.
llvm-svn: 201052
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.
llvm-svn: 201051
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.
llvm-svn: 201050
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.
llvm-svn: 201049
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.
llvm-svn: 201048
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.
llvm-svn: 201047
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.
llvm-svn: 201044
