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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@68420 91177308-0d34-0410-b5e6-96231b3b80d8
is appropriate. This helps visually differentiate host-oriented
calculations from target-oriented calculations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@68227 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56622 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56233 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55969 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54899 91177308-0d34-0410-b5e6-96231b3b80d8
a new ilist_node class, and remove them. Unlike alist_node,
ilist_node doesn't attempt to manage storage itself, so it avoids
the associated problems, including being opaque in gdb.
Adjust the Recycler class so that it doesn't depend on alist_node.
Also, change it to use explicit Size and Align parameters, allowing
it to work when the largest-sized node doesn't have the greatest
alignment requirement.
Change MachineInstr's MachineMemOperand list from a pool-backed
alist to a std::list for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54146 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53941 91177308-0d34-0410-b5e6-96231b3b80d8
folded. Remove code that handled the case where they aren't
folded, and remove bitcode reader/writer support for them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53887 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53275 91177308-0d34-0410-b5e6-96231b3b80d8
and bitcode support for the extractvalue and insertvalue
instructions and constant expressions.
Note that this does not yet include CodeGen support.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51468 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44858 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44769 91177308-0d34-0410-b5e6-96231b3b80d8
http://llvm.org/viewvc/llvm-project?rev=44199&view=rev
This patch completely broke serialization due to an invariant I assumed but
did not hold. The assumed invariant was that all pointer IDs emitted by a call
to BatchEmitOwnedPtrs would be consecutive. This is only the case if there has
been no forward references to an owned pointer (and hence already registered
with the Serializer object).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44203 91177308-0d34-0410-b5e6-96231b3b80d8
Deserialize::ReadDiffPtrID to read and emit bools instead of unsigned
integers. This should result in a nice space optimization once we have
"auto-abbreviation" generation in place.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44200 91177308-0d34-0410-b5e6-96231b3b80d8
SerializedPtrID, followed by the *differences* in IDs. The big idea is that
most IDs will be just be 1 off from the previous (either that or NULL, which
we encode as a difference if 0), so this will greatly reduce the encoding
space for extra IDs to just 1 bit per pointer.
So far this optimization reduces serialization of Carbon.h by only 1%, but
we aren't using any abbreviations now in the Bitcode file to properly take
advantage of this optimization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44199 91177308-0d34-0410-b5e6-96231b3b80d8
deserialize objects if BatchReadOwnedPtrs was called more than once in the
same call chain then the second call would overwrite the SerializedPtrIDs
being used by the first call. Solved this problem by making the vector that
holds the pointer IDs local to a function call. Now BatchReadOwnedPtrs is
reentrant.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44152 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44021 91177308-0d34-0410-b5e6-96231b3b80d8
deserialization as a temporary location for storing serialized pointer identifiers. The
definition of SerializedPtrID will likely change significantly in the future, and the
current implementation caused compilation errors on some 64-bit machines.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43983 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43973 91177308-0d34-0410-b5e6-96231b3b80d8
Moved some of the logic in BitstreamReader::ExitBlock into a utility function
BitstreamReader::PopBlockScope. The latter is a private method. It will also
be called by Deserializer to manipulate the current "block scope."
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43972 91177308-0d34-0410-b5e6-96231b3b80d8
