into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.
There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.
The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.
I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).
I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171366 91177308-0d34-0410-b5e6-96231b3b80d8
When aliasing tools, rather than using the base TOOLEXENAME, we should
instead use the built tool's basename (for 'make') or the installed
tool's basename (for 'make install').
This should not cause any changes for anyone building unprefixed 'clang'
and 'clang++' tools.
Patch by Rick Foos!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165189 91177308-0d34-0410-b5e6-96231b3b80d8
The Apple buildbots have been modified not to pass --target,
so they shouldn't choke on a default program prefix anymore.
Patch by Rick Foos!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164956 91177308-0d34-0410-b5e6-96231b3b80d8
The Apple buildbots are set up to pass --target to configure for both
cross- and non-cross-compile builds, and the standard autoconf response
to this is to set the program prefix to '<target>-'. Until we can figure
out the proper way to handle this (don't pass --target? pass an explicit
--program-prefix=""? don't auto-populate program_prefix with target_alias?)
it's more important to keep the buildbots running.
This reverts r164633 / ba48ceb1a3.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164651 91177308-0d34-0410-b5e6-96231b3b80d8
to store additional flag options since too many things can
and do override CPPFLAGS. Also, this is exported, unlike CPPFLAGS
so it can be actually used elsewhere. This should enable us
to remove the AC_SUBSTs in the intel checks, but I have no way
of testing it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161233 91177308-0d34-0410-b5e6-96231b3b80d8
optional library support to the llvm-build tool:
- Add new command line parameter to llvm-build: “--enable-optional-libraries”
- Add handing of new llvm-build library type “OptionalLibrary”
- Update Cmake and automake build systems to pass correct flags to llvm-build
based on configuration
Patch by Dan Malea!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156319 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-ld is no longer useful and causes confusion and so it is being removed.
* Does not work very well on Windows because it must call a gcc like driver to
assemble and link.
* Has lots of hard coded paths which are wrong on many systems.
* Does not understand most of ld's options.
* Can be partially replaced by llvm-link | opt | {llc | as, llc -filetype=obj} |
ld, or fully replaced by Clang.
I know of no production use of llvm-ld, and hacking use should be
replaced by Clang's driver.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155147 91177308-0d34-0410-b5e6-96231b3b80d8
- On OS X 10.7+ this is apparently recommended practice. This maybe should
become a configurey thing one day, but I'm not sure it is right to
automatically turn it on.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152133 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 was disabled years ago because of a bug in GCC 4.1, which is
on our "broken compilers" list for other reasons. Saving ~500k
on a clang binary (Release+Asserts) is well worth dropping support
for it.
We currently disable it for shared libraries (where it would bring
the biggest win) because clang is broken (PR11642).
IMPORTANT: If you're doing incremental builds you may get tons of
linker warnings. make clean will fix them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147182 91177308-0d34-0410-b5e6-96231b3b80d8
Original commit message:
llvm-config: Replace with C++ version (was llvm-config-2).
- Reapply of r144300, with lots of fixes/migration easement in between.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145582 91177308-0d34-0410-b5e6-96231b3b80d8
Some files installed by clang are not relevant for general users and we'd like
to be able to install them to a different location. This adds a new
--with-internal-prefix configure option and a corresponding PROJ_internal_prefix
makefile variable, which defaults to the standard prefix. A tool makefile
can specify that it should be installed to this internal prefix by defining
INTERNAL_TOOL.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145234 91177308-0d34-0410-b5e6-96231b3b80d8
TARGETS_TO_BUILD variables to build tools submake, and also tweak echo command
to indicate when we are compiling/etc build tools.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144419 91177308-0d34-0410-b5e6-96231b3b80d8
some more of the explicit dependencies. I'm staging things more slowly this time
in case there is more unanticipated fallout.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144323 91177308-0d34-0410-b5e6-96231b3b80d8
to delete core files. This causes a warning in clang/lib/StaticAnalyzer on
case insensitive filesystems, since it contains a "Core" directory. Since this
is pointless anyway, just zap it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144317 91177308-0d34-0410-b5e6-96231b3b80d8
- Basically, we coordinate with llvm-build to create a Makefile fragment we can
easily use. For now, nothing is wired in except the support to automatically
regenerate this file when necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143662 91177308-0d34-0410-b5e6-96231b3b80d8
This allows the (many) pseudo-instructions we have that map onto a single
real instruction to have their expansion during MC lowering handled
automatically instead of the current cumbersome manual expansion required.
These sorts of pseudos are common when an instruction is used in situations
that require different MachineInstr flags (isTerminator, isBranch, et. al.)
than the generic instruction description has. For example, using a move
to the PC to implement a branch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134704 91177308-0d34-0410-b5e6-96231b3b80d8
target machine from those that are only needed by codegen. The goal is to
sink the essential target description into MC layer so we can start building
MC based tools without needing to link in the entire codegen.
First step is to refactor TargetRegisterInfo. This patch added a base class
MCRegisterInfo which TargetRegisterInfo is derived from. Changed TableGen to
separate register description from the rest of the stuff.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133782 91177308-0d34-0410-b5e6-96231b3b80d8
config.cache will be used by the person who specifies '-C' to configure.
config.cache's inconsistency should be responsible to him.
Re-configuration would spend so much on cygming without '-C', esp. cygwin.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133252 91177308-0d34-0410-b5e6-96231b3b80d8
If enabled, this will attempt to use the CC_LOG_DIAGNOSTICS feature I dropped
into Clang to print a log of all the diagnostics generated during an individual
build (from the top-level). Not sure if this will actually be useful, but for
now it is handy for testing the option.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129312 91177308-0d34-0410-b5e6-96231b3b80d8
It broke the llvm-gcc-native-mingw32 buildbot, and we need all of them to be green for the 2.9 branch.
Takumi, please reapply after we branch, preferably with a fix ;-)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127107 91177308-0d34-0410-b5e6-96231b3b80d8
them on install. Before we would have LLVMgold.so on the build directory but
libLLVMgold.so on the install dir.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124821 91177308-0d34-0410-b5e6-96231b3b80d8
GNU ld/PECOFF accepts but ignores them below;
--version-script
--export-dynamic
--rpath
FIXME: autoconf should be aware of them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120179 91177308-0d34-0410-b5e6-96231b3b80d8
as the operator of the dag. Specifically, this allows parsing things
like (F.x 4) in addition to just (a 4).
Unfortunately, this runs afoul of an idiom being used by llvmc. It
is using dags like (foo [1,2,3]) to represent a list of stuff being
passed into foo. With this change, this is parsed as a [1,2,3]
subscript on foo instead of being the first argument to the dag.
Cope with this in the short term by requiring a "-llvmc-temp-hack"
argument to tblgen to get the old parsing behavior.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115742 91177308-0d34-0410-b5e6-96231b3b80d8
delay. Anton and PIC16 folks, if this is still good to keep, please go ahead
and add it back in with an updated comment about when would be a good time
to revisit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115358 91177308-0d34-0410-b5e6-96231b3b80d8
