Move all of the header files which are involved in modelling the LLVM IR
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long

Move all of the header files which are involved in modelling the LLVM IR
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.

llvm-svn: 171366

show more ...

Use the new script to sort the includes of every file under lib.

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module

Use the new script to sort the includes of every file under lib.

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.

Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]

llvm-svn: 169131

show more ...

Revert the majority of the next patch in the address space series:

r165941: Resubmit the changes to llvm core to update the functions to
support different pointer sizes on a per address spa

Revert the majority of the next patch in the address space series:

r165941: Resubmit the changes to llvm core to update the functions to
support different pointer sizes on a per address space basis.

Despite this commit log, this change primarily changed stuff outside of
VMCore, and those changes do not carry any tests for correctness (or
even plausibility), and we have consistently found questionable or flat
out incorrect cases in these changes. Most of them are probably correct,
but we need to devise a system that makes it more clear when we have
handled the address space concerns correctly, and ideally each pass that
gets updated would receive an accompanying test case that exercises that
pass specificaly w.r.t. alternate address spaces.

However, from this commit, I have retained the new C API entry points.
Those were an orthogonal change that probably should have been split
apart, but they seem entirely good.

In several places the changes were very obvious cleanups with no actual
multiple address space code added; these I have not reverted when
I spotted them.

In a few other places there were merge conflicts due to a cleaner
solution being implemented later, often not using address spaces at all.
In those cases, I've preserved the new code which isn't address space
dependent.

This is part of my ongoing effort to clean out the partial address space
code which carries high risk and low test coverage, and not likely to be
finished before the 3.2 release looms closer. Duncan and I would both
like to see the above issues addressed before we return to these
changes.

llvm-svn: 167222

show more ...

Resubmit the changes to llvm core to update the functions to support different pointer sizes on a per address space basis.

llvm-svn: 165941

Revert 165732 for further review.

llvm-svn: 165747

Add in the first iteration of support for llvm/clang/lldb to allow variable per address space pointer sizes to be optimized correctly.

llvm-svn: 165726

Move TargetData to DataLayout.

llvm-svn: 165402

EE/Interpreter/ExternalFunctions.cpp: Staticize lle_X_() entries. They can be mapped in FuncNames[] at the initialization.

llvm-svn: 151313

EE/Interpreter/ExternalFunctions.cpp: Prune "C" linkage to suppress warnings with -Wreturn-type (and MSC's w4190).

In historical reason, Interpreter's external entries had prefix "lle_X_" as C linka

EE/Interpreter/ExternalFunctions.cpp: Prune "C" linkage to suppress warnings with -Wreturn-type (and MSC's w4190).

In historical reason, Interpreter's external entries had prefix "lle_X_" as C linkage, even for well-known entries in EE/Interpreter.
Now, at least on ToT, they are resolved via FuncNames[] mapper.
We will not need their symbols are expected to be exported any more.

Clang r150128 has introduced the warning <"%0 has C-linkage specified, but returns user-defined type %1 which is incompatible with C">.

llvm-svn: 151312

show more ...

Using the new external-linkage warning recently added instead of disabling all return type warnings.

llvm-svn: 150512

Fixing warning due to the new "UTD return type in extern 'C'".

Patch by Matt Johnson

llvm-svn: 150508

More dead code removal (using -Wunreachable-code)

llvm-svn: 148578

Remove all remaining uses of Value::getNameStr().

llvm-svn: 144648

land David Blaikie's patch to de-constify Type, with a few tweaks.

llvm-svn: 135375

Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deleti

Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)

Removing almost 3K lines of code is a good thing. Other advantages
include:

1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.

Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.

There are still some cleanups pending after this, this patch is large enough
as-is.

llvm-svn: 134829

show more ...

eliminate the Type::getDescription() method, using "<<" instead. This
removes some gunk from LLVMContext.

llvm-svn: 133360

Merge System into Support.

llvm-svn: 120298

Convert some tab stops into spaces.

llvm-svn: 108130

rename llvm::llvm_report_error -> llvm::report_fatal_error

llvm-svn: 100709

Typo noticed by Duncan.

llvm-svn: 99918

Don't overwrite previous value, if it succeeded.

llvm-svn: 99886

Honour addGlobalMapping() in the interpreter, if it was used to add mappings for
external Functions (the JIT does honour this).

llvm-svn: 99885

Replace strcpy with memcpy when we have the length around anyway.

llvm-svn: 94746

These should probably be errs().

llvm-svn: 92673

Change errs() to dbgs().

llvm-svn: 92618