This patch allows us to use cmake to specify a cross compiler: target different
than host. In particular, it moves LLVM_DEFAULT_TARGET_TRIPLE and TARGET_TRIPLE
variables from cmake/config-ix.cmake to the toplevel CMakeLists.txt to make them
available at configure time.
Here is the command line that I have used to test my patches to create a Hexagon
cross compiler hosted on x86:
$ cmake -G Ninja -D LLVM_TARGETS_TO_BUILD:STRING=Hexagon -D TARGET_TRIPLE:STRING=hexagon-unknown-linux-gnu -D LLVM_DEFAULT_TARGET_TRIPLE:STRING=hexagon-unknown-linux-gnu -D LLVM_TARGET_ARCH:STRING=hexagon-unknown-linux-gnu ..
$ ninja check
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162219 91177308-0d34-0410-b5e6-96231b3b80d8
This patch allows us to use cmake to specify a cross compiler for Hexagon.
In particular, the patch adds a missing case for the target Hexagon in
cmake/config-ix.cmake, and it moves LLVM_DEFAULT_TARGET_TRIPLE and TARGET_TRIPLE
variables from cmake/config-ix.cmake to the toplevel CMakeLists.txt to make them
available at configure time. Here is the command line that I have used to test
my patches:
$ cmake -G Ninja -D BUILD_SHARED_LIBS:BOOL=ON -D LLVM_TARGETS_TO_BUILD:STRING=Hexagon -D TARGET_TRIPLE:STRING=hexagon-unknown-linux-gnu -D LLVM_DEFAULT_TARGET_TRIPLE:STRING=hexagon-unknown-linux-gnu -D LLVM_TARGET_ARCH:STRING=hexagon-unknown-linux-gnu -D LLVM_ENABLE_PIC:BOOL=OFF ..
$ ninja check
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161504 91177308-0d34-0410-b5e6-96231b3b80d8
in the abstraction for lit test suites so that the various other layers
of abstraction pick up the same behavioral fix, and so that we still get
a complete list of dependencies for the 'check-all' target.
This should fix the follow-on issues of the same nature with various
other build targets, including Clang targets. Sorry for the churn, and
again thanks to Matt for testing and breaking this more thoroughly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159593 91177308-0d34-0410-b5e6-96231b3b80d8
due to strange scoping rules to the actual canonical variable name
within the LLVM CMake build.
No functionality changed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159575 91177308-0d34-0410-b5e6-96231b3b80d8
re-used. Also, build in direct support for accumulating a set of lit
parameters, arguments, and testsuites to run as part of a 'check-all'
rule. This sinks 'check-all' from a Clang-specific construct to
a generic construct of the project.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159482 91177308-0d34-0410-b5e6-96231b3b80d8
Makefiles, the CMake files in every other part of the LLVM tree, and
sanity.
This should also restore the output tree structure of all the unit
tests, sorry for breaking that, and thanks for letting me know.
The fundamental change is to put a CMakeLists.txt file in the unittest
directory, with a single test binary produced from it. This has several
advantages:
- No more weird directory stripping in the unittest macro, allowing it
to be used more readily in other projects.
- No more directory prefixes on all the source files.
- Allows correct and precise use of LLVM's per-directory dependency
system.
- Allows use of the checking logic for source files that have not been
added to the CMake build. This uncovered a file being skipped with
CMake in LLVM and one in Clang's unit tests.
- Makes Specifying conditional compilation or other custom logic for JIT
tests easier.
It did require adding the concept of an explicit 'optional' source file
to the CMake build so that the missing-file check can skip cases where
the file is *supposed* to be missing. =]
This is another chunk of refactoring the CMake build in order to make it
usable for other clients like CompilerRT / ASan / TSan.
Note that this is interdependent with a Clang CMake change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158909 91177308-0d34-0410-b5e6-96231b3b80d8
a helper function in CMake. This will allow us to share all of this
logic with Clang, and eventually CompilerRT.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158896 91177308-0d34-0410-b5e6-96231b3b80d8
facilities.
This was only used in one place in LLVM, and was used pervasively (but
with different code!) in Clang. It has no advantages over the standard
CMake facilities and in some cases disadvantages.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158889 91177308-0d34-0410-b5e6-96231b3b80d8
This was previously only done for executables and shared libraries, but not
for modules. As modules are essentially shared libraries (that need to be
dlopened explicitly), threating them the same as shared libraries seems
reasonable. This fixes the LLVM_BUILD_32_BITS build of Polly.
Contributed by: Ondra Hosek <ondra.hosek@gmail.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158195 91177308-0d34-0410-b5e6-96231b3b80d8
output. Peter Collingbourne also reports that it is showing up in
$(llvm-config --cflags).
Revert this for now since I don't know enough cmake to fix it properly.
This reverts commit 18efed7adc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156392 91177308-0d34-0410-b5e6-96231b3b80d8
While making lld build under the tools directory I decided to refactor how this
works.
There is now a macro, add_llvm_external_project, which takes the name of the
expected subdirectory. This sets up two CMake options.
* LLVM_EXTERNAL_${NAME}_SOURCE_DIR
This is the path to the source. It defaults to
${CMAKE_CURRENT_SOURCE_DIR}/${name}.
* LLVM_EXTERNAL_${NAME}_BUILD
Enable and disable building the tool as part of LLVM.
I chose LLVM_EXTERNAL_${NAME} as a prefix so they all show up together in the
GUI.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155654 91177308-0d34-0410-b5e6-96231b3b80d8
Clang builds. The detection logic for compilers that support the warning
isn't working. Rafael is going to investigate it, but didn't want people
to have to wade through build spam until then.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151649 91177308-0d34-0410-b5e6-96231b3b80d8
This is useful for clients that want to maintain compatibility
across multiple releases of LLVM. Currently users like Klee and
Mesa all have to roll their own 'parse llvm-config --version
output and generate defines' solution.
Also reuse the new macros so that version information is less
redundant/likely to fall out of sync again in the future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150405 91177308-0d34-0410-b5e6-96231b3b80d8
dealing in the host triple, be honest about it and document the decision
to default the target triple to the host triple unless overridden.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148822 91177308-0d34-0410-b5e6-96231b3b80d8
Get back getHostTriple.
For JIT compilation, use the host triple instead of the default
target: this fixes some JIT testcases that used to fail when the
compiler has been configured as a cross compiler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147542 91177308-0d34-0410-b5e6-96231b3b80d8
revision and git commit data extracted. This will be used in the Clang
CMake build to avoid trying to re-detect the information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146324 91177308-0d34-0410-b5e6-96231b3b80d8
in CMake a bit more handy. Previously we would get such charming
versions as the following for revision NNNN and commit-ish XXXXX:
3.1svnsvn-rNNNN
3.1svngit-svn-rNNNN
3.1svngit-svn-XXXXX
The mechanism selecting betwene the latter two was particularly odd, and
didn't work with all of the ways git-svn repos are set up apparently. It
also misses an important point -- both the revision *and* the git commit
might be relevant when working on a local branch some distance from
mainline. The new logic does several things:
1) It strips the redundant initial 'svn'.
2) It always looks for a git-svn revision number base, and when found
includes it in the version.
3) If the git commit-ish for the current HEAD is not exactly that
revision number, it is also included.
The resulting strings should roughly be:
3.1svn-rNNNN
3.1git-svn-rNNNN
3.1git-svn-rNNNN-XXXXX
Suggestions on formatting etc always welcome. =] I've only looked at the
LLVM version string here, not Clang's (yet).
Note that the commit-ish reported is *not* terribly accurate. It updates
when 'cmake' is run, not when the binary is built. Still, it may be
better than nothing, especially if people have fairly long-lived git
repos and branches. This is not a new limitation, just didn't want
anyone to be surprised.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146323 91177308-0d34-0410-b5e6-96231b3b80d8
- I verified locally that the current dependency lists are identical.
- This makes add_llvm_library_dependencies() a no-op. I'll remove it once this
change passes the bots.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145355 91177308-0d34-0410-b5e6-96231b3b80d8
Now that it needs to be exported in a public header (Valgrind.h)
it should be prefixed to avoid collision with other projects.
Add it to llvm-config.h as well.
This'll require regenerating the configure script after this
commit, but I don't have the required autoconf version.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145214 91177308-0d34-0410-b5e6-96231b3b80d8
CMAKE_CONFIGURATION_TYPES is only set on Visual Studio generators. For NMake CMAKE_BUILD_TYPE is used instead.
Patch by EJose Fonseca!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143898 91177308-0d34-0410-b5e6-96231b3b80d8
one aspect of them by having them use the (annoying, if not broken)
proper library dependency model for adding the LLVMTableGen library as
a dependency. This could manifest as a link order issue in the presence
of separate LLVM / Clang source builds with CMake and a linker that
really cares about such things.
Also, add the Support dependency to llvm-tblgen itself so that it
doesn't rely on TableGen's transitive Support dependency. A parallel
change for clang-tblgen will be forthcoming.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143531 91177308-0d34-0410-b5e6-96231b3b80d8
(void)static_func; it is used as idiom in llvm source tree to suppress "Unused static function" warnings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137800 91177308-0d34-0410-b5e6-96231b3b80d8
sub-library for the targets depended on the core target CodeGen library.
This completely undermined the careful work to separate the those
libraries, especially the MC-layer ones. This surfaced as circular
dependencies when the libraries were built as shared libraries where
CMake doesn't allow cycles.
This should fix PR10537. I'll watch the bots to see if there is fallout
on other platforms.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136565 91177308-0d34-0410-b5e6-96231b3b80d8
globally scoped constructs. Also, round-trip these dependencies through
the LLVMConfig.cmake.in file thata is used by CMake-based clients of
"installed" (or built) LLVM trees.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136543 91177308-0d34-0410-b5e6-96231b3b80d8
specified in the same file that the library itself is created. This is
more idiomatic for CMake builds, and also allows us to correctly specify
dependencies that are missed due to bugs in the GenLibDeps perl script,
or change from compiler to compiler. On Linux, this returns CMake to
a place where it can relably rebuild several targets of LLVM.
I have tried not to change the dependencies from the ones in the current
auto-generated file. The only places I've really diverged are in places
where I was seeing link failures, and added a dependency. The goal of
this patch is not to start changing the dependencies, merely to move
them into the correct location, and an explicit form that we can control
and change when necessary.
This also removes a serialization point in the build because we don't
have to scan all the libraries before we begin building various tools.
We no longer have a step of the build that regenerates a file inside the
source tree. A few other associated cleanups fall out of this.
This isn't really finished yet though. After talking to dgregor he urged
switching to a single CMake macro to construct libraries with both
sources and dependencies in the arguments. Migrating from the two macros
to that style will be a follow-up patch.
Also, llvm-config is still generated with GenLibDeps.pl, which means it
still has slightly buggy dependencies. The internal CMake
'llvm-config-like' macro uses the correct explicitly specified
dependencies however. A future patch will switch llvm-config generation
(when using CMake) to be based on these deps as well.
This may well break Windows. I'm getting a machine set up now to dig
into any failures there. If anyone can chime in with problems they see
or ideas of how to solve them for Windows, much appreciated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136433 91177308-0d34-0410-b5e6-96231b3b80d8
The first problem to fix is to stop creating synthetic *Table_gen
targets next to all of the LLVM libraries. These had no real effect as
CMake specifies that add_custom_command(OUTPUT ...) directives (what the
'tablegen(...)' stuff expands to) are implicitly added as dependencies
to all the rules in that CMakeLists.txt.
These synthetic rules started to cause problems as we started more and
more heavily using tablegen files from *subdirectories* of the one where
they were generated. Within those directories, the set of tablegen
outputs was still available and so these synthetic rules added them as
dependencies of those subdirectories. However, they were no longer
properly associated with the custom command to generate them. Most of
the time this "just worked" because something would get to the parent
directory first, and run tablegen there. Once run, the files existed and
the build proceeded happily. However, as more and more subdirectories
have started using this, the probability of this failing to happen has
increased. Recently with the MC refactorings, it became quite common for
me when touching a large enough number of targets.
To add insult to injury, several of the backends *tried* to fix this by
adding explicit dependencies back to the parent directory's tablegen
rules, but those dependencies didn't work as expected -- they weren't
forming a linear chain, they were adding another thread in the race.
This patch removes these synthetic rules completely, and adds a much
simpler function to declare explicitly that a collection of tablegen'ed
files are referenced by other libraries. From that, we can add explicit
dependencies from the smaller libraries (such as every architectures
Desc library) on this and correctly form a linear sequence. All of the
backends are updated to use it, sometimes replacing the existing attempt
at adding a dependency, sometimes adding a previously missing dependency
edge.
Please let me know if this causes any problems, but it fixes a rather
persistent and problematic source of build flakiness on our end.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136023 91177308-0d34-0410-b5e6-96231b3b80d8
refactorings. Several places that shouldn't have dependend on Target no
longer do. Also almost all of the CodeGen dependencies have gone away
for the MCDisassembler. Others add reasonable dependencies within the
target-specific layers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135977 91177308-0d34-0410-b5e6-96231b3b80d8
The header file was already properly located. The previous need for it
in Support had to do with the version string printing which was fixed in
r135757.
Also update build dependencies where libraries that needed the
functionality of the Target library (in the form of the TargetRegistry)
were picking it up via Support. This is pretty pervasive, essentially
every TargetInfo library (ARMInfo, etc) uses TargetRegistry, making it
depend on Target. All of these were previously just sneaking by.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135760 91177308-0d34-0410-b5e6-96231b3b80d8
Evan's recent refactorings (I believe). Specifically, MCDisassembler no
longer depends on Target, and ARMDisassembler no longer depends on
CodeGen. The added dependencies from ARMAsmParser to ARMDesc looks
correct based on header file inclusion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135759 91177308-0d34-0410-b5e6-96231b3b80d8
(including compilation, assembly). Move relocation model Reloc::Model from
TargetMachine to MCCodeGenInfo so it's accessible even without TargetMachine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135468 91177308-0d34-0410-b5e6-96231b3b80d8
backend. Moved some MCAsmInfo files down into the MCTargetDesc
sublibraries, removed some (i suspect long) dead files from other parts
of the CMake build, etc. Also copied the include directory hack from the
Makefile.
Finally, updated the lib deps. I spot checked this, and think its
correct, but review appreciated there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135234 91177308-0d34-0410-b5e6-96231b3b80d8
It's now replaced with a simple ifdef _MSC_VER in the one
place it's needed (clang's FileManager.h header).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133711 91177308-0d34-0410-b5e6-96231b3b80d8
Take #2. Don't piggyback on the existing config.build_mode. Instead,
define a new lit feature for each build feature we need (currently
just "asserts"). Teach both autoconf'd and cmake'd Makefiles to define
this feature within test/lit.site.cfg. This doesn't require any lit
harness changes and should be more robust across build systems.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133664 91177308-0d34-0410-b5e6-96231b3b80d8
under cmake).
Add libprofile_rt.a so that we can tell clang to link against it in --coverage
mode. Also turn it on by default in cmake builds.
Oscar, this touches a change you made for EXCLUDE_FROM_ALL support -- I think
I've done the right thing, but please let me know (or fix and commit) if not!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@130470 91177308-0d34-0410-b5e6-96231b3b80d8
component names such as "engine" do not expand to "jit" and hence to
the native target libraries for external users.
Thanks to arrowdodger for reporting and diagnosing the problem.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129444 91177308-0d34-0410-b5e6-96231b3b80d8
If someone first configure build with LLVM_ENABLE_FFI=1 and then turn it
off, the build will fail in lib/ExecutionEngine/Interpreter because
Interpreter will try still to #include <ffi/ffi.h>, but there are no
include_directories(${FFI_INCLUDE_DIR}) now.
This patch unset()'s HAVE_FFI_H and HAVE_FFI_FFI_H from cache file if
LLVM_ENABLE_FFI=0. This forces CMake to update config.h.
Patch by arrowdodger!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128769 91177308-0d34-0410-b5e6-96231b3b80d8
with the contents of CMAKE_C(XX)_FLAGS too, else `llvm-config
--c(xx)flags' doesn't tell the absolute truth.
This comes from PR9603 and is based on a patch by Ryuta Suzuki!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128727 91177308-0d34-0410-b5e6-96231b3b80d8
unnecesary conditionals and introduced a new convenience function.
The problem was that the list of libraries for Clang's unit tests was
<clang libraries> <system libraries> <llvm libraries>. As the llvm
libraries references symbols defined on the system libraries, those
were reported as undefined.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128484 91177308-0d34-0410-b5e6-96231b3b80d8
Now we can remove RuntimeDyld from the LLVM_LINK_COMPONENTS of
tools/lli. CMakeLists.txt LLVM_LINK_COMPONENTS shall not differ from
its companion Makefile LINK_COMPONENTS.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128069 91177308-0d34-0410-b5e6-96231b3b80d8
Without this cmake fails at configuration when some target pass
"native" on LLVM_LINK_COMPONENTS and that is expanded to "X86".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127679 91177308-0d34-0410-b5e6-96231b3b80d8
before the main loop. This is necessary because the loop ignores the
items added to `link_components' after it is entered.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127333 91177308-0d34-0410-b5e6-96231b3b80d8
of testing for its presence at cmake time.
This way the build automatically regenerates the makefiles when a svn
update brings in a new sublibrary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126068 91177308-0d34-0410-b5e6-96231b3b80d8
AC_CHECK_FUNCS seeks a symbol only in libs. We should check the declaration in string.h.
FIXME: I have never seen mingw(s) have strerror_s() (not _strerror_s()).
FIXME: Autoconf/CMake may seek strerror_s() with the definition MINGW_HAS_SECURE_API in future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125172 91177308-0d34-0410-b5e6-96231b3b80d8
config.h.* have conditions whether each symbol is defined or not.
Autoconf and CMake may check symbols in libgcc.a for JIT on Mingw.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124950 91177308-0d34-0410-b5e6-96231b3b80d8
library.
Installs tblgen (required by Clang).
Translates handling of user settings and platform-dependant options to
its own file, where it can included by another project.
Installs the .cmake files required by projects like Clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124816 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-config --cflags --cxxflags --cppflags
We shouldn't impose those flags on people who use llvm-config for
building their own projects.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124399 91177308-0d34-0410-b5e6-96231b3b80d8
config.h was generated, so it had no effect on it.
Thanks to arrowdodger for pointing out this and a tentative patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123119 91177308-0d34-0410-b5e6-96231b3b80d8
(clang/include/clang/Basic/StmtNodes.td, for instance, is tablegenned
from clang/include/clang/AST/CMakeLists.txt) so it is not contained on
the list of all .td files on the current source directory which is
used as the DEPENDS of the custom command. We must add the .td file to
the DEPENDS list of the custom command. Otherwise some .inc files are
not regenerated when the corresponding .td file changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122768 91177308-0d34-0410-b5e6-96231b3b80d8
options. If we are building with exceptions/rtti disabled, we replace
/EHsc with /EHs-c- and /GR with /GR-, respectively. If we just add the
disabling options we get warnings like this:
cl : Command line warning D9025 : overriding '/EHs' with '/EHs-'
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122648 91177308-0d34-0410-b5e6-96231b3b80d8
cmake/modules/AddLLVM.cmake: Add empty "phony" target in add_llvm_loadable_module() even if loadable module were not supported.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121455 91177308-0d34-0410-b5e6-96231b3b80d8
2. Parsing .word directive in MBlaze asm parser
3. Fixing hack where memory instructions reversed order of last two parameters
4. Fixing many improperly encoded instructions
5. Support parsing special instructions (MFS,MTS,etc.)
6. Removing unused functions from inst printer
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@118941 91177308-0d34-0410-b5e6-96231b3b80d8
mostly based on the ARM AsmParser at this time and is not particularly
functional.
Changed the MBlaze data layout from:
"E-p:32:32-i8:8:8-i16:16:16-i64:32:32-f64:32:32-v64:32:32-v128:32:32-n32"
to:
"E-p:32:32:32-i8:8:8-i16:16:16"
because the MicroBlaze doesn't have i64, f64, v64, or v128 data types.
Cleaned up the MBlaze source code:
1. The floating point register class has been removed. The
MicroBlaze does not have floating point registers. Floating
point values are simply stored in integer registers.
2. Renaming the CPURegs register class to GPR to reflect the
standard naming.
3. Removing a lot of stale code from AsmPrinter after
the conversion to InstPrinter.
4. Simplified sign extended loads by marking them as
expanded in ISelLowering.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@117054 91177308-0d34-0410-b5e6-96231b3b80d8
1. A delay slot filler that searches for valid instructions
to fill the delay slot with. Previously NOPs would always
be inserted into delay slots.
2. Support for MC based instruction printer added.
3. Support for MC based machine code generation and ELF
file generation. ELF file generation does not yet
completely work as much of the ELF support infrastructure
is still x86/x86-64 specific.
4. General clean up of the MBlaze backend code. Much of the
tablegen code has been cleanup and simplified.
Bug Fixes:
1. Removed duplicate periods from subtarget feature descriptions.
2. Many of the instructions had bad machine code information
in the tablegen files. Much of this has been fixed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116986 91177308-0d34-0410-b5e6-96231b3b80d8
available targets unless LLVM_INCLUDE_X is ON. LLVM_BUILD_X implies
LLVM_INCLUDE_X"
It breaks the configuration phase when cmake is invoked without
parameters, it is too complex for the purpose and introduces an
incovenience for the user (as both LLVM_BUILD_X and LLVM_INCLUDE_X
must set to OFF for not including X on the build)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114795 91177308-0d34-0410-b5e6-96231b3b80d8
The cmake (+ MSVC) build is broken if you don't select your native
target.
e.g. 'cmake -D LLVM_TARGETS_TO_BUILD="MyNonNativeTarget" .'
This is because cmake currently sets the LLVM_NATIVE_* definitions
regardless of whether the native target is selected (causing build
errors).
Patch by Mike Gist!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112946 91177308-0d34-0410-b5e6-96231b3b80d8
that like to randomly define things like "X86", regenerate autoconf bits
and update cmake.
Fixes PR7852.
Patch by Xerxes Rånby!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112499 91177308-0d34-0410-b5e6-96231b3b80d8
The user can use a cmake function for obtaining the LLVM libraries
corresponding to a list of LLVM components.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110560 91177308-0d34-0410-b5e6-96231b3b80d8
Is setted on a per build type basis. This is useful for generators
that comprise several build types, i.e. VC++ solutions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110296 91177308-0d34-0410-b5e6-96231b3b80d8
XCore->XCoreGen
PIC16->PIC16CodeGen
After updating your working copy, the first build will fail because it
is using the old library dependencies. Start the build again and it
will work fine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110127 91177308-0d34-0410-b5e6-96231b3b80d8
is a dependence on an LLVM target that is not included on the build.
When LLVM_TARGETS_TO_BUILD didn't include all the targets, the
function emitted an error like
"Library LLVMArmParser not found in list of llvm libraries."
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110060 91177308-0d34-0410-b5e6-96231b3b80d8
incarnations), integrated into the MC framework.
The disassembler is table-driven, using a custom TableGen backend to
generate hierarchical tables optimized for fast decode. The disassembler
consumes MemoryObjects and produces arrays of MCInsts, adhering to the
abstract base class MCDisassembler (llvm/MC/MCDisassembler.h).
The disassembler is documented in detail in
- lib/Target/X86/Disassembler/X86Disassembler.cpp (disassembler runtime)
- utils/TableGen/DisassemblerEmitter.cpp (table emitter)
You can test the disassembler by running llvm-mc -disassemble for i386
or x86_64 targets. Please let me know if you encounter any problems
with it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91749 91177308-0d34-0410-b5e6-96231b3b80d8
functions like floorf, ceilf, ... Add test for detecting nearbyintf.
This change was prompted by test/Transforms/SimplifyLibCalls/floor.ll
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86954 91177308-0d34-0410-b5e6-96231b3b80d8
directory.
This is useful in case someone who works with the config&make build
system forgot to add a file to its CMakeLists.txt. Instead of
obtaining undefined references at link time, cmake will complain at
configure time on the first build after a svn update.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85817 91177308-0d34-0410-b5e6-96231b3b80d8
setenv(). This patch just disables the test rather than getting putenv() to
work. Thanks to Sandeep Patel for reporting the problem.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82797 91177308-0d34-0410-b5e6-96231b3b80d8
A include/llvm/ADT/iterator.cmake
U autoconf/configure.ac
--- Reverse-merging r80161 into '.':
U cmake/config-ix.cmake
--- Reverse-merging r80171 into '.':
U Makefile
--- Reverse-merging r80173 into '.':
U configure
U include/llvm/Config/config.h.in
--- Reverse-merging r80180 into '.':
A include/llvm/ADT/iterator.h.in
Despite common miscomceptions, iterator.h is alive and well. It broke the build
bots for several hours. And yet no one bothered to look at them.
Gabor and Doug, please review your changes and make sure that they actually
build before resubmitting them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80197 91177308-0d34-0410-b5e6-96231b3b80d8
- I did not actually remove the configure test itself, someone who can
regenerate configure should do this (see FIXME in autoconf/configure.ac)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79881 91177308-0d34-0410-b5e6-96231b3b80d8
failure with VS 9.0, nmake and cmake 2.6.4. The buildbot output does
not show the patch level of cmake, it just says 2.6.
Sadly, parallel builds are broken due to recent changes on LLVM Target
libraries and its auxiliaries (TargetInfo, AsmPrinter, AsmParser). I
have a patch for stablishing the correct dependencies, but cmake is
buggy and generates makefiles that can't handle them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79180 91177308-0d34-0410-b5e6-96231b3b80d8
It doesn't stop or reconfigure the build, though, so the user will see
a broken build that magically succeeds at the next attempt. It is
technically possible to halt the build with a helpful message, and
even to automatically restart the build using the new dependencies as
it we did when llvm-config was used by cmake for learning
dependencies. This is left on the TODO list.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79004 91177308-0d34-0410-b5e6-96231b3b80d8
way we ensure that tablegenned files exist before they are #include'd
by the LLVM Target sublibraries. Required for parallel builds.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78996 91177308-0d34-0410-b5e6-96231b3b80d8
libraries for an executable.
Now LLVMConfig uses a new system for sorting library dependencies, as
the list of dependent libraries for each entry of FinalLibDeps.txt no
longer is topologically sorted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78787 91177308-0d34-0410-b5e6-96231b3b80d8
- This isn't needed anymore, we require clients to call the appropriate
initialization routines using TargetSelect.h.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75871 91177308-0d34-0410-b5e6-96231b3b80d8
TARGET component.
- Also, updated some CMake library dependencies, it is still missing some
though. :(
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75755 91177308-0d34-0410-b5e6-96231b3b80d8
Windows variant, strerror_s, but I couldn't test that.
I'll update configure and config.h.in in a subsequent patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74621 91177308-0d34-0410-b5e6-96231b3b80d8
of compiler parameters explicitly added by the build
specification. This macro replaces the cmake built-in
`add_definitions'.
Detects glibc and defines _GNU_SOURCE accordingly.
Resolves bug 3882.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@68428 91177308-0d34-0410-b5e6-96231b3b80d8
Hopefully this doesn't break anyone else's build... it shouldn't unless
the MinGW variable means something other than compiling with MinGW.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60273 91177308-0d34-0410-b5e6-96231b3b80d8
and siblings. Support targets whose name does not end on
`CodeGen'. Remove a performance bottleneck.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59383 91177308-0d34-0410-b5e6-96231b3b80d8
dummy library, `llvm_headers_do_not_build', is created for containing
all header and TableGen files under include/llvm.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59346 91177308-0d34-0410-b5e6-96231b3b80d8
