Constant, MDString and MDNode which can only be used by globals with a name
that starts with "llvm." or as arguments to a function with the same naming
restriction.
llvm-svn: 68420
same as a normal i80 {low64, high16} rather
than its own {high64, low16}. A depressing number
of places know about this; I think I got them all.
Bitcode readers and writers convert back to the old
form to avoid breaking compatibility.
llvm-svn: 67562
changes.
For InvokeInst now all arguments begin at op_begin().
The Callee, Cont and Fail are now faster to get by
access relative to op_end().
This patch introduces some temporary uglyness in CallSite.
Next I'll bring CallInst up to a similar scheme and then
the uglyness will magically vanish.
This patch also exposes all the reliance of the libraries
on InvokeInst's operand ordering. I am thinking of taking
care of that too.
llvm-svn: 66920
and extern_weak_odr. These are the same as the non-odr versions,
except that they indicate that the global will only be overridden
by an *equivalent* global. In C, a function with weak linkage can
be overridden by a function which behaves completely differently.
This means that IP passes have to skip weak functions, since any
deductions made from the function definition might be wrong, since
the definition could be replaced by something completely different
at link time. This is not allowed in C++, thanks to the ODR
(One-Definition-Rule): if a function is replaced by another at
link-time, then the new function must be the same as the original
function. If a language knows that a function or other global can
only be overridden by an equivalent global, it can give it the
weak_odr linkage type, and the optimizers will understand that it
is alright to make deductions based on the function body. The
code generators on the other hand map weak and weak_odr linkage
to the same thing.
llvm-svn: 66339
alignment attribute such that 0 means unaligned.
This will probably require a rebuild of llvm-gcc because of the change to
Attributes.h. If you see many test failures on "make check", please rebuild
your llvm-gcc.
llvm-svn: 61030
callee will not introduce any new aliases of that pointer.
The attributes had all bits allocated already, so I decided to collapse
alignment. Alignment was previously stored as a 16-bit integer from bits 16 to
32 of the attribute, but it was required to be a power of 2. Now it's stored in
log2 encoded form in five bits from 16 to 21. That gives us 11 more bits of
space.
You may have already noticed that you only need four bits to encode a 16-bit
power of two, so why five bits? Because the AsmParser accepted 32-bit
alignments, even though we couldn't store them (they were silently discarded).
Now we can store them in memory, but not in the bitcode.
The bitcode format was already storing these as 64-bit VBR integers. So, the
bitcode format stays the same, keeping the alignment values stored as 16 bit
raw values. There's some hideous code in the reader and writer that deals with
this, waiting to be ripped out the moment we run out of bits again and have to
replace the parameter attributes table encoding.
llvm-svn: 61019
- return attributes - inreg, zext and sext
- parameter attributes
- function attributes - nounwind, readonly, readnone, noreturn
Return attributes use 0 as the index.
Function attributes use ~0U as the index.
This patch requires corresponding changes in llvm-gcc and clang.
llvm-svn: 56704
s/ParamAttr/Attribute/g
s/PAList/AttrList/g
s/FnAttributeWithIndex/AttributeWithIndex/g
s/FnAttr/Attribute/g
This sets the stage
- to implement function notes as function attributes and
- to distinguish between function attributes and return value attributes.
This requires corresponding changes in llvm-gcc and clang.
llvm-svn: 56622
bitcode reader/writer as follows:
- add and use new bitcode FUNC_CODE_INST_VSELECT to handle the llvm
select opcode using either i1 or [N x i1] as the selector.
- retain old BITCODE FUNC_CODE_INST_SELECT in the bitcode reader to
handle select on i1 for backwards compatibility with existing bitcode
files.
- re-enable the vector-select.ll test program.
Also, rename the recently added bitcode opcode FUNC_CODE_INST_VCMP to
FUNC_CODE_INST_CMP2 and make the bitcode writer use it to handle
fcmp/icmp on scalars or vectors. In the bitcode writer, use
FUNC_CODE_INST_CMP for vfcmp/vicmp only. In the bitcode reader, have
FUNC_CODE_INST_CMP handle icmp/fcmp returning bool, for backwards
compatibility with existing bitcode files.
Patch by Preston Gurd!
llvm-svn: 56233
and, if so, to return a vector of boolean as a result;
Extend the select LLVM IR instruction to allow you to specify a result
type which is a vector of boolean, in which case the result will be an
element-wise selection instead of choosing one vector or the other; and
Update LangRef.html to describe these changes.
This patch was contributed by Preston Gurd!
llvm-svn: 55969
In particular, Collector was confusing to implementors. Several
thought that this compile-time class was the place to implement
their runtime GC heap. Of course, it doesn't even exist at runtime.
Specifically, the renames are:
Collector -> GCStrategy
CollectorMetadata -> GCFunctionInfo
CollectorModuleMetadata -> GCModuleInfo
CollectorRegistry -> GCRegistry
Function::getCollector -> getGC (setGC, hasGC, clearGC)
Several accessors and nested types have also been renamed to be
consistent. These changes should be obvious.
llvm-svn: 54899
Remove the GetResultInst instruction. It is still accepted in LLVM assembly
and bitcode, where it is now auto-upgraded to ExtractValueInst. Also, remove
support for return instructions with multiple values. These are auto-upgraded
to use InsertValueInst instructions.
The IRBuilder still accepts multiple-value returns, and auto-upgrades them
to InsertValueInst instructions.
llvm-svn: 53941
bc files for modules with a target triple that indicates they are for
darwin. The reader unconditionally handles this, and the writer could
turn this on for more targets if we care.
This change has two benefits for darwin:
1) it allows us to encode the cpu type of the file in an easy to read
place that doesn't require decoding the bc file.
2) it works around a bug (IMO) in darwin's AR where it is incapable of
handling files that are not a multiple of 8 bytes long. BC files
are only guaranteed to be multiples of 4 bytes long.
llvm-svn: 53275
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
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
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
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
Thompson. Usage should be something like this:
open Llvm
open Llvm_bitreader
match read_bitcode_file fn with
| Bitreader_failure msg ->
prerr_endline msg
| Bitreader_success m ->
...;
dispose_module m
Compile with: ocamlc llvm.cma llvm_bitreader.cma
ocamlopt llvm.cmxa llvm_bitreader.cmxa
llvm-svn: 44824
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
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
any sense it is important that ParamAttr::None gets
treated the same as not supplying an attribute at
all. Rather than stripping ParamAttr::None out of
the list of attributes, assert if ParamAttr::None
is seen. Fix up the bitcode reader which liked to
insert ParamAttr::None all over the place. Patch
based on one by Török Edwin.
llvm-svn: 44250
the deserializer.
Fixed assertion when "stream jumping" in the deserializer to properly function
when we have reached the end of the stream.
llvm-svn: 44124
clients of the Deserializer to read the pointer ID before they are ready
to deserialize the object (which can mean registering a pointer reference
with the backpatcher).
Changed some methods that took an argument "SerializedPtrID" to "const SerializedPtrID&" (pass-by-reference). This is to accommodate a future
revision of SerializedPtrID where it may be much fatter than an unsigned
integer.
llvm-svn: 44021
serialized block in the bitstream, including a block in an entirely different
nesting than the current block. This is useful for deserializing objects from
a bitstream in an order different from the order that they were serialized.
llvm-svn: 43973
block that is being visited in the bitstream. The client can also now
skip blocks before reading them, and query the current abbreviation number
as seen from the perspective of the Deserializer. This allows the client
to be more interactive in the deserialization process (if they so choose).
llvm-svn: 43916
instead of just using "unsigned". This gives us more flexibility in changing
the definition of the handle later, and is more self-documenting.
Added tracking of block stack in the Deserializer. Now clients can query
if they are still within a block using the methods GetCurrentBlockLocation()
and FinishedBlock().
llvm-svn: 43903
Deserializer.
There were issues with Visual C++ barfing when instantiating
SerializeTrait<T> when "T" was an abstract class AND
SerializeTrait<T>::ReadVal was *never* called:
template <typename T>
struct SerializeTrait {
<SNIP>
static inline T ReadVal(Deserializer& D) { T::ReadVal(D); }
<SNIP>
};
Visual C++ would complain about "T" being an abstract class, even
though ReadVal was never instantiated (although one of the other
member functions were).
Removing this from the trait is not a big deal. It was used hardly
ever, and users who want "read-by-value" deserialization can simply
call the appropriate methods directly instead of relying on
trait-based-dispatch. The trait dispatch for
serialization/deserialization is simply sugar in many cases (like this
one).
llvm-svn: 43624
flag in the **key** of the backpatch map, as opposed to the mapped
value which contains either the final pointer, or a pointer to a chain
of pointers that need to be backpatched. The bit flag was moved to
the key because we were erroneously assuming that the backpatched
pointers would be at an alignment of >= 2 bytes, which obviously
doesn't work for character strings. Now we just steal the bit from the key.
llvm-svn: 43595
just like pointers, except that they cannot be backpatched. This
means that references are essentially non-owning pointers where the
referred object must be deserialized prior to the reference being
deserialized. Because of the nature of references, this ordering of
objects is always possible.
Fixed a bug in backpatching code (returning the backpatched pointer
would accidentally include a bit flag).
llvm-svn: 43570
eager backpatching instead of waithing until all objects have been
deserialized. This allows us to reduce the memory footprint needed
for backpatching.
llvm-svn: 43422
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
- The naming prefix is LLVM.
- All types are represented using opaque references.
- Functions are not named LLVM{Type}{Method}; the names became
unreadable goop. Instead, they are named LLVM{ImperativeSentence}.
- Where an attribute only appears once in the class hierarchy (e.g.,
linkage only applies to values; parameter types only apply to
function types), the class is omitted from identifiers for
brevity. Tastes like methods.
- Strings are C strings or string/length tuples on a case-by-case
basis.
- APIs which give the caller ownership of an object are not mapped
(removeFromParent, certain constructor overloads). This keeps
keep memory management as simple as possible.
For each library with bindings:
llvm-c/<LIB>.h - Declares the bindings.
lib/<LIB>/<LIB>.cpp - Implements the bindings.
So just link with the library of your choice and use the C header
instead of the C++ one.
llvm-svn: 42077
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
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
This also changes the syntax for llvm.bswap, llvm.part.set, llvm.part.select, and llvm.ct* intrinsics. They are automatically upgraded by both the LLVM ASM reader and the bitcode reader. The test cases have been updated, with special tests added to ensure the automatic upgrading is supported.
llvm-svn: 40807
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
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
relieves us from having to emit the abbrevs into each instance of the block.
This shrinks kc.bit from 3368K to 3333K, but will be a more significant win
once instructions are abbreviated.
The VST went from:
Block ID #14 (VALUE_SYMTAB):
Num Instances: 2345
Total Size: 1.29508e+07b/1.61885e+06B/404713W
Average Size: 5522.73b/690.342B/172.585W
% of file: 48.0645
Tot/Avg SubBlocks: 0/0
Tot/Avg Abbrevs: 7035/3
Tot/Avg Records: 120924/51.5667
% Abbrev Recs: 100
to:
Block ID #14 (VALUE_SYMTAB):
Num Instances: 2345
Total Size: 1.26713e+07b/1.58391e+06B/395978W
Average Size: 5403.53b/675.442B/168.86W
% of file: 47.5198
Tot/Avg SubBlocks: 0/0
Tot/Avg Abbrevs: 0/0
Tot/Avg Records: 120924/51.5667
% Abbrev Recs: 100
because we didn't emit the same 3 abbrevs 2345 times :)
llvm-svn: 36767
where we can. This shrinks kc++'s down to 3368K, with a VST record of:
Block ID #14 (VALUE_SYMTAB):
Num Instances: 2345
Total Size: 1.29508e+07b/1.61885e+06B/404713W
Average Size: 5522.73b/690.342B/172.585W
% of file: 48.0645
Tot/Avg SubBlocks: 0/0
Tot/Avg Abbrevs: 7035/3
Tot/Avg Records: 120924/51.5667
% Abbrev Recs: 100
Isn't it nice to be able to optimizer bc size without touching the reader? :)
llvm-svn: 36759
integer structure idx's are emitted before constant expr geps) and shrinks
files slightly. For example kc++ shrinks from 4326188 to 4240128 bytes.
llvm-svn: 36742
trip function bodies like this:
define <2 x i64> @foo(<2 x i64> %x, <2 x i64> %y) {
%tmp4 = bitcast <2 x i64> %y to <8 x i16> ; <<8 x i16>> [#uses=1]
%tmp5 = bitcast <2 x i64> %x to <8 x i16> ; <<8 x i16>> [#uses=1]
%tmp = add <8 x i16> %tmp5, %tmp4 ; <<8 x i16>> [#uses=1]
%tmp6 = bitcast <8 x i16> %tmp to <2 x i64> ; <<2 x i64>> [#uses=1]
ret <2 x i64> %tmp6
}
llvm-svn: 36640
anything about disk I/O itself. This greatly simplifies its interface -
eliminating the need for the ReaderWrappers.cpp file.
This adds a new option to llvm-dis (-bitcode) which instructs it to read
the input file as bitcode. Until/unless the bytecode reader is taught to
read from MemoryBuffer, there is no way to handle stdin reading without it.
I don't plan to switch the bytecode reader over, I'd rather delete it :),
so the option will stay around temporarily.
llvm-svn: 36554
Nick Lewycky