| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 51822
|
|
|
|
|
|
|
|
|
|
|
| |
insertvalue and extractvalue to use constant indices instead of
Value* indices. And begin updating LangRef.html.
There's definately more to come here, but I'm checking this
basic support in now to make it available to people who are
interested.
llvm-svn: 51806
|
|
|
|
|
|
|
|
|
| |
and bitcode support for the extractvalue and insertvalue
instructions and constant expressions.
Note that this does not yet include CodeGen support.
llvm-svn: 51468
|
|
|
|
|
|
|
|
| |
This changes the .bc file format, but if I understand
how it works correctly, old .bc files continue to
be readable.
llvm-svn: 51161
|
|
|
|
|
|
|
|
|
|
| |
are represented as "weak", but there are subtle differences
in some cases on Darwin, so we need both. The intent
is that "common" will behave identically to "weak" unless
somebody changes their target to do something else.
No functional change as yet.
llvm-svn: 51118
|
|
|
|
|
|
| |
for details. CodeGen support coming in a follow up patch
llvm-svn: 50985
|
|
|
|
|
|
| |
r48047 r48084 r48085 r48086 r48088 r48096 r48099 r48109 and r48123.
llvm-svn: 50265
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. There is now a "PAListPtr" class, which is a smart pointer around
the underlying uniqued parameter attribute list object, and manages
its refcount. It is now impossible to mess up the refcount.
2. PAListPtr is now the main interface to the underlying object, and
the underlying object is now completely opaque.
3. Implementation details like SmallVector and FoldingSet are now no
longer part of the interface.
4. You can create a PAListPtr with an arbitrary sequence of
ParamAttrsWithIndex's, no need to make a SmallVector of a specific
size (you can just use an array or scalar or vector if you wish).
5. All the client code that had to check for a null pointer before
dereferencing the pointer is simplified to just access the
PAListPtr directly.
6. The interfaces for adding attrs to a list and removing them is a
bit simpler.
Phase #2 will rename some stuff (e.g. PAListPtr) and do other less
invasive changes.
llvm-svn: 48289
|
|
|
|
| |
llvm-svn: 48248
|
|
|
|
|
|
| |
This is the first checkin for PR1269, the new EH infrastructure.
llvm-svn: 47802
|
|
|
|
| |
llvm-svn: 47585
|
|
|
|
|
|
| |
Take 2.
llvm-svn: 47583
|
|
|
|
| |
llvm-svn: 47533
|
|
|
|
| |
llvm-svn: 47521
|
|
|
|
|
|
|
| |
stuff into ParamAttrsList.h. Per feedback from
ParamAttrs changes.
llvm-svn: 47504
|
|
|
|
| |
llvm-svn: 47471
|
|
|
|
| |
llvm-svn: 47401
|
|
|
|
|
|
|
| |
for adding alignment info, not there yet). Clean up
interfaces to reference ParameterAttributes consistently.
llvm-svn: 47342
|
|
|
|
| |
llvm-svn: 45418
|
|
|
|
| |
llvm-svn: 44933
|
|
|
|
| |
llvm-svn: 44864
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
regions of memory that have a target specific relationship, as described in the
Embedded C Technical Report.
This also implements the 2007-12-11-AddressSpaces test,
which demonstrates how address space attributes can be used in LLVM IR.
In addition, this patch changes the bitcode signature for stores (in a backwards
compatible manner), such that the pointer type, rather than the pointee type, is
encoded. This permits type information in the pointer (e.g. address space) to be
preserved for stores.
LangRef updates are forthcoming.
llvm-svn: 44858
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
methods are new to Function:
bool hasCollector() const;
const std::string &getCollector() const;
void setCollector(const std::string &);
void clearCollector();
The assembly representation is as such:
define void @f() gc "shadow-stack" { ...
The implementation uses an on-the-side table to map Functions to
collector names, such that there is no overhead. A StringPool is
further used to unique collector names, which are extremely
likely to be unique per process.
llvm-svn: 44769
|
|
|
|
|
|
|
| |
introduced by this patch:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071126/055824.html
llvm-svn: 44364
|
|
|
|
|
|
|
|
|
|
|
|
| |
the function type, instead they belong to functions
and function calls. This is an updated and slightly
corrected version of Reid Spencer's original patch.
The only known problem is that auto-upgrading of
bitcode files doesn't seem to work properly (see
test/Bitcode/AutoUpgradeIntrinsics.ll). Hopefully
a bitcode guru (who might that be? :) ) will fix it.
llvm-svn: 44359
|
|
|
|
|
|
|
|
|
| |
No compile-time support for constant operations yet,
just format transformations. Make readers and
writers work. Split constants into 2 doubles in
Legalize.
llvm-svn: 42865
|
|
|
|
|
|
| |
destruction of compiler-created ones.
llvm-svn: 42383
|
|
|
|
|
|
|
| |
Next round of x87 long double stuff.
Getting close now, basically works.
llvm-svn: 41875
|
|
|
|
|
|
|
|
|
| |
access to bits). Use them in place of float and
double interfaces where appropriate.
First bits of x86 long double constants handling
(untested, probably does not work).
llvm-svn: 41858
|
|
|
|
| |
llvm-svn: 41769
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use APFloat in UpgradeParser and AsmParser.
Change all references to ConstantFP to use the
APFloat interface rather than double. Remove
the ConstantFP double interfaces.
Use APFloat functions for constant folding arithmetic
and comparisons.
(There are still way too many places APFloat is
just a wrapper around host float/double, but we're
getting there.)
llvm-svn: 41747
|
|
|
|
|
|
|
|
|
|
|
|
| |
to handle values bigger than double. If we assume host==target and host
long double works correctly, this is not too bad, but we don't want to
have that limitation longterm. I could implement accepting double
constants as long double or something like that, which would lead to
incorrect codegen with no errors; the more I think about that the worse
it seems. Rather than do such a hack that would be backed out later,
I'm settling for giving reasonable error messages, for now.
llvm-svn: 40974
|
|
|
|
| |
llvm-svn: 40774
|
|
|
|
| |
llvm-svn: 37916
|
|
|
|
|
|
| |
the functions which haven't been read.
llvm-svn: 36999
|
|
|
|
|
|
|
| |
pr1146 in llvm 2.1 without ugly code to emulate old behavior. This should
be merged into the 2.0 release branch.
llvm-svn: 36928
|
|
|
|
|
|
| |
ofstreams will be ok.
llvm-svn: 36878
|
|
|
|
| |
llvm-svn: 36831
|
|
|
|
|
|
| |
bytes.
llvm-svn: 36829
|
|
|
|
| |
llvm-svn: 36827
|
|
|
|
| |
llvm-svn: 36823
|
|
|
|
|
|
| |
well. This shrinks kc++ from 2724088 to 2717360 bytes.
llvm-svn: 36821
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
block from:
Block ID #11 (CONSTANTS_BLOCK):
Num Instances: 1722
Total Size: 3.85976e+06b/482470B/120617W
% of file: 16.7609
Average Size: 2241.44b/280.18B/70.045W
Tot/Avg SubBlocks: 0/0
Tot/Avg Abbrevs: 1/0.00058072
Tot/Avg Records: 26423/15.3444
% Abbrev Recs: 69.1746
to:
Block ID #11 (CONSTANTS_BLOCK):
Num Instances: 1724
Total Size: 2.62406e+06b/328008B/82001.9W
% of file: 12.041
Average Size: 1522.08b/190.26B/47.5649W
Tot/Avg SubBlocks: 0/0
Tot/Avg Abbrevs: 2/0.00116009
Tot/Avg Records: 26280/15.2436
% Abbrev Recs: 68.9992
This shrinks kc++ from 2815788 to 2724088 bytes, which means the bitcode
file is now smaller than the bytecode file.
llvm-svn: 36820
|
|
|
|
|
|
| |
2878544 to 2815788
llvm-svn: 36818
|
|
|
|
|
|
| |
shrinks function bodies in kc++ from 891913B to 884073B
llvm-svn: 36817
|
|
|
|
|
|
| |
This shrinks the function block of kc++ from 1055K to 906K
llvm-svn: 36816
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Block ID #12 (FUNCTION_BLOCK):
Num Instances: 2344
Total Size: 8.8434e+06b/1.10542e+06B/276356W
% of file: 35.6726
Average Size: 3772.78b/471.598B/117.899W
Tot/Avg SubBlocks: 4065/1.73422
Tot/Avg Abbrevs: 0/0
Tot/Avg Records: 128487/54.8153
% Abbrev Recs: 0
to:
Block ID #12 (FUNCTION_BLOCK):
Num Instances: 2344
Total Size: 8.44518e+06b/1.05565e+06B/263912W
% of file: 34.6203
Average Size: 3602.89b/450.362B/112.59W
Tot/Avg SubBlocks: 4065/1.73422
Tot/Avg Abbrevs: 0/0
Tot/Avg Records: 128487/54.8153
% Abbrev Recs: 22.2077
llvm-svn: 36779
|
|
|
|
|
|
| |
to 3.85972e6 bits in kc++
llvm-svn: 36778
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This shrinks the type_block of kc++ from 139901 bits to 99389 bits (0.55% to 0.39%
of the file), a 40% reduction.
This shrink the record from:
Block ID #10 (TYPE_BLOCK):
Num Instances: 1
Total Size: 139901b/17487.6B/4371.91W
% of file: 0.549306
Num Abbrevs: 0
Num Records: 3203
% Abbrev Recs: 0
to:
Block ID #10 (TYPE_BLOCK):
Num Instances: 1
Total Size: 99389b/12423.6B/3105.91W
% of file: 0.390862
Num Abbrevs: 4
Num Records: 3203
% Abbrev Recs: 99.6566
With a common histogram of:
Code Histogram:
1613 POINTER
1100 FUNCTION
255 STRUCT
224 ARRAY
5 INTEGER
2 OPAQUE
1 LABEL
1 DOUBLE
1 VOID
1 NUMENTRY
llvm-svn: 36776
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with 6 bits where possible. This shrinks kc++ from 3324164B to 3183584B. The
old VST was:
Block ID #14 (VALUE_SYMTAB):
Total Size: 1.26713e+07b/1.58391e+06B/395978W
Average Size: 5403.53b/675.442B/168.86W
% of file: 47.6484
The new one is:
Block ID #14 (VALUE_SYMTAB):
Total Size: 1.15467e+07b/1.44334e+06B/360834W
Average Size: 4923.96b/615.495B/153.874W
% of file: 45.3368
This is 11% smaller than the VST in the bytecode format.
llvm-svn: 36771
|