Commit Graph

79 Commits

Author SHA1 Message Date
Chandler Carruth 8a8cd2bab9 Re-sort all of the includes with ./utils/sort_includes.py so that
subsequent changes are easier to review. About to fix some layering
issues, and wanted to separate out the necessary churn.

Also comment and sink the include of "Windows.h" in three .inc files to
match the usage in Memory.inc.

llvm-svn: 198685
2014-01-07 11:48:04 +00:00
Rafael Espindola 2b11ad4fe9 Use error_code in GVMaterializer.
They just propagate out the bitcode reader error, so we don't need a new enum.

llvm-svn: 194091
2013-11-05 19:36:34 +00:00
Rafael Espindola 7d712031e1 Convert FindFunctionInStream to return an error_code.
llvm-svn: 194084
2013-11-05 17:16:08 +00:00
Rafael Espindola 48da4f4691 Change BitcodeReader to use error_code instead of bool + string.
In order to create an ObjectFile implementation that uses bitcode files, we
need to propagate the bitcode errors to the ObjectFile interface, so we need
to convert it to use the same error handling as ObjectFile: error_code.

llvm-svn: 193996
2013-11-04 16:16:24 +00:00
Manman Ren 209b17cdaa AutoUpgrade: upgrade from scalar TBAA format to struct-path aware TBAA format.
We treat TBAA tags as struct-path aware TBAA format when the first operand
is a MDNode and the tag has 3 or more operands.

llvm-svn: 191593
2013-09-28 00:22:27 +00:00
Peter Collingbourne 3fa50f9b05 Implement function prefix data as an IR feature.
Previous discussion:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063909.html

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

llvm-svn: 190773
2013-09-16 01:08:15 +00:00
Benjamin Kramer 079b96e6f7 Revert "Give internal classes hidden visibility."
It works with clang, but GCC has different rules so we can't make all of those
hidden. This reverts commit r190534.

llvm-svn: 190536
2013-09-11 18:05:11 +00:00
Benjamin Kramer 6a44af3629 Give internal classes hidden visibility.
Worth 100k on a linux/x86_64 Release+Asserts clang.

llvm-svn: 190534
2013-09-11 17:42:27 +00:00
Tobias Grosser 0a8e12fdbb Make .bc en/decoding of AttrKind stable
The bitcode representation attribute kinds are encoded into / decoded from
should be independent of the current set of LLVM attributes and their position
in the AttrKind enum. This patch explicitly encodes attributes to fixed bitcode
values.

With this patch applied, LLVM does not silently misread attributes written by
LLVM 3.3. We also enhance the decoding slightly such that an error message is
printed if an unknown AttrKind encoding was dected.

Bonus: Dropping bitcode attributes from AttrKind is now easy, as old AttrKinds
       do not need to be kept to support the Bitcode reader.
llvm-svn: 187186
2013-07-26 04:16:55 +00:00
Craig Topper 2cd5ff8003 Use SmallVectorImpl& instead of SmallVector to avoid repeating small vector size.
llvm-svn: 186098
2013-07-11 16:22:38 +00:00
Bill Wendling e46707e4c7 Use a std::map so that we record the group ID.
llvm-svn: 174910
2013-02-11 22:32:29 +00:00
Bill Wendling ba629335de Add support in the bitcode reader to read the attribute groups.
This reads the attribute groups. It currently doesn't do anything with them.

NOTE: In the commit to the bitcode writer, the format *may* change in the near
future. Which means that this code would also change.

llvm-svn: 174849
2013-02-10 23:24:25 +00:00
Chandler Carruth 9fb823bbd4 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
2013-01-02 11:36:10 +00:00
Bill Wendling e94d843e43 s/AttrListPtr/AttributeSet/g to better label what this class is going to be in the near future.
llvm-svn: 169651
2012-12-07 23:16:57 +00:00
Chandler Carruth 802d755533 Sort includes for all of the .h files under the 'lib' tree. These were
missed in the first pass because the script didn't yet handle include
guards.

Note that the script is now able to handle all of these headers without
manual edits. =]

llvm-svn: 169224
2012-12-04 07:12:27 +00:00
Joe Abbey 2ad8df24ec Code Custodian:
- Widespread trailing space removal
  - A dash of OCD spacing to block align enums
  - joined a line that probably needed 80 cols a while back

llvm-svn: 168566
2012-11-25 15:23:39 +00:00
Jan Wen Voung 8c9e941196 Fix some typos 165739, spotted by Duncan.
llvm-svn: 165753
2012-10-11 21:45:16 +00:00
Jan Wen Voung afaced070f Change encoding of instruction operands in bitcode binaries to be relative
to the instruction position.  The old encoding would give an absolute
ID which counts up within a function, and only resets at the next function.

I.e., Instead of having:

... = icmp eq i32 n-1, n-2
br i1 ..., label %bb1, label %bb2

it will now be roughly:

... = icmp eq i32 1, 2
br i1 1, label %bb1, label %bb2

This makes it so that ids remain relatively small and can be encoded
in fewer bits.

With this encoding, forward reference operands will be given
negative-valued IDs.  Use signed VBRs for the most common case
of forward references, which is phi instructions.

To retain backward compatibility we bump the bitcode version
from 0 to 1 to distinguish between the different encodings.

llvm-svn: 165739
2012-10-11 20:20:40 +00:00
Derek Schuff 92ef975cc5 Fix PR12080 by ensuring that MaterializeModule actually reads all the bitcode
in the streaming case.

llvm-svn: 151676
2012-02-29 00:07:09 +00:00
Derek Schuff 8b2dcad4b5 Enable streaming of bitcode
This CL delays reading of function bodies from initial parse until
materialization, allowing overlap of compilation with bitcode download.

llvm-svn: 149918
2012-02-06 22:30:29 +00:00
Rafael Espindola b79934657c Materialize functions whose basic blocks are used by global variables. Fixes
PR11677.

llvm-svn: 147425
2012-01-02 07:49:53 +00:00
Chad Rosier ca2567b861 Begin adding experimental support for preserving use-list ordering of bitcode
files.  First, add a new block USELIST_BLOCK to the bitcode format.  This is 
where USELIST_CODE_ENTRYs will be stored.  The format of the USELIST_CODE_ENTRYs
have not yet been defined.  Add support in the BitcodeReader for parsing the
USELIST_BLOCK.
Part of rdar://9860654 and PR5680.

llvm-svn: 146078
2011-12-07 21:44:12 +00:00
Chris Lattner 1c9e5678b8 remove support for reading llvm 2.9 .bc files. LLVM 3.1 is only compatible back to 3.0
llvm-svn: 145164
2011-11-27 05:48:27 +00:00
Chris Lattner 229907cd11 land David Blaikie's patch to de-constify Type, with a few tweaks.
llvm-svn: 135375
2011-07-18 04:54:35 +00:00
Chris Lattner b1ed91f397 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
2011-07-09 17:41:24 +00:00