| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 78948
|
| |
|
|
|
|
|
|
| |
while
the latter is capable of representing either a primitive or an extended type.
llvm-svn: 78713
|
| |
|
|
|
|
| |
arguments that are vectors of any size and element type.
llvm-svn: 78631
|
| |
|
|
|
|
| |
own struct type.
llvm-svn: 78610
|
| |
|
|
|
|
| |
contexts through a number of APIs.
llvm-svn: 78258
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the return type of the intrinsic is not overloaded, i.e., where the type
being matched is some other parameter. The argument to LLVMMatchType is
an index into the list of overloaded types (ignoring the fixed types),
but VerifyIntrinsicPrototype is expecting its arguments for LLVMMatchType
parameters to be indices into the combined list of _all_ return values and
parameters, not just the overloaded ones.
This patch changes TableGen to keep track for each overloaded type of the
corresponding index into the list of return values and parameters. It
then generates the values expected by VerifyIntrinsicPrototype.
llvm-svn: 77467
|
| |
|
|
| |
llvm-svn: 74882
|
| |
|
|
|
|
|
|
| |
- Sorry, I can't help myself.
- No intended functionality change.
llvm-svn: 74742
|
| |
|
|
|
|
|
|
| |
arguments/elements
to not have to create a temporary vector (in the API at least). Patch by Jay Foad!
llvm-svn: 74584
|
| |
|
|
|
|
|
|
|
|
| |
and argument positions but only to the overloaded intrinsic parameters.
Keep a separate list of these overloaded parameters in CodeGenTarget.cpp
so they can be resolved easily. Remove assertions from IntrinsicEmitter.cpp:
they were harmless but confusing, and the assertions elsewhere in TableGen
will catch any incorrect values.
llvm-svn: 69316
|
| |
|
|
| |
llvm-svn: 67758
|
| |
|
|
|
|
| |
or target) can be overloaded or not.
llvm-svn: 65404
|
| |
|
|
|
|
| |
intrinsics to any IntrWriteArgMem intrinsics.
llvm-svn: 64551
|
| |
|
|
| |
llvm-svn: 63812
|
| |
|
|
|
|
| |
and llvm-gcc.
llvm-svn: 63786
|
| |
|
|
|
|
|
|
|
| |
target directories themselves. This also means that VMCore no longer
needs to know about every target's list of intrinsics. Future work
will include converting the PowerPC target to this interface as an
example implementation.
llvm-svn: 63765
|
| |
|
|
|
|
|
| |
llvm.memcpy/memset/memmove. This allows removal of some
hackish code from basicaa.
llvm-svn: 62071
|
| |
|
|
|
|
| |
change.
llvm-svn: 62067
|
| |
|
|
|
|
| |
not a random piece of it. No functionality change.
llvm-svn: 62066
|
| |
|
|
|
|
|
|
| |
to handle LLVMMatchType intrinsic parameters, and by adding new subclasses
of LLVMMatchType to match vector types with integral elements that are
either twice as wide or half as wide as the elements of the matched type.
llvm-svn: 61834
|
| |
|
|
| |
llvm-svn: 59242
|
| |
|
|
| |
llvm-svn: 59241
|
| |
|
|
|
|
|
|
|
|
| |
"parameter" types. An intrinsic can now return a multiple return values like
this:
def add_with_overflow : Intrinsic<[llvm_i32_ty, llvm_i1_ty],
[LLVMMatchType<0>, LLVMMatchType<0>]>;
llvm-svn: 59237
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
to different address spaces. This alters the naming scheme for those
intrinsics, e.g., atomic.load.add.i32 => atomic.load.add.i32.p0i32
llvm-svn: 54195
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and better control the abstraction. Rename the type
to MVT. To update out-of-tree patches, the main
thing to do is to rename MVT::ValueType to MVT, and
rewrite expressions like MVT::getSizeInBits(VT) in
the form VT.getSizeInBits(). Use VT.getSimpleVT()
to extract a MVT::SimpleValueType for use in switch
statements (you will get an assert failure if VT is
an extended value type - these shouldn't exist after
type legalization).
This results in a small speedup of codegen and no
new testsuite failures (x86-64 linux).
llvm-svn: 52044
|
| |
|
|
|
|
| |
the VC++ 'nesting depth' issue.
llvm-svn: 45567
|
| |
|
|
| |
llvm-svn: 45563
|
| |
|
|
|
|
|
|
|
|
| |
if (!strcmp(Target, "x86")) {
// ...
}
else
IntrinsicID = Intrinsic::not_intrinsic;
llvm-svn: 45557
|
| |
|
|
|
|
|
| |
comparison for every builtin. This reduces the depth of
the if/elseif chain dramatically.
llvm-svn: 45500
|
| |
|
|
| |
llvm-svn: 45419
|
| |
|
|
|
|
| |
of PointerType::get() has become PointerType::getUnqual(), which returns a pointer in the generic address space. The new prototype of PointerType::get() requires both a type and an address space.
llvm-svn: 45082
|
| |
|
|
|
|
|
|
|
| |
throw exceptions", just mark intrinsics with the nounwind
attribute. Likewise, mark intrinsics as readnone/readonly
and get rid of special aliasing logic (which didn't use
anything more than this anyway).
llvm-svn: 44544
|
| |
|
|
| |
llvm-svn: 42423
|
| |
|
|
| |
llvm-svn: 41128
|
| |
|
|
|
|
| |
information for overloaded intrinsics (PR1600). This resolves that issue, and improves the matching scheme to use a BitVector rather than a binary search.
llvm-svn: 40872
|
| |
|
|
|
|
|
|
| |
LLVM. It cleans up the intrinsic definitions and generally smooths the process for more complicated intrinsic writing. It will be used by the upcoming atomic intrinsics as well as vector and float intrinsics in the future.
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
|
| |
|
|
| |
llvm-svn: 40527
|
| |
|
|
| |
llvm-svn: 37727
|
| |
|
|
|
|
|
|
| |
types of the iAny types involved in the overloaded intrinsic. Thus, we
can't use the argument number as the index but have to count them separately
in order to index Tys correctly. This patch rectifies this situation.
llvm-svn: 37296
|
| |
|
|
|
|
|
|
| |
Don't assert everytime an intrinsic name isn't recognized. Instead, make
the assert optional when callin getIntrinsicID(). This allows the assembler
to handle invalid intrinsic names gracefully.
llvm-svn: 36120
|
| |
|
|
|
|
|
|
|
|
| |
Implement code generation for overloaded intrinsic functions. The basic
difference is that "actual" argument types must be provided when
constructing intrinsic names and types. Also, for recognition, only the
prefix is examined. If it matches, the suffix is assumed to match. The
suffix is checked by the Verifier, however.
llvm-svn: 35539
|
| |
|
|
| |
llvm-svn: 34321
|
| |
|
|
|
|
| |
which allocates a string. This speeds up instcombine on 447.dealII by 5%.
llvm-svn: 34318
|
| |
|
|
|
|
|
| |
Change use of "packed" term to "vector" in comments, strings, variable
names, etc.
llvm-svn: 34300
|
| |
|
|
|
|
|
| |
Rename PackedType -> VectorType, ConstantPacked -> ConstantVector, and
PackedTyID -> VectorTyID. No functional changes.
llvm-svn: 34293
|
| |
|
|
|
|
|
| |
to construct FunctionType in separate function, and, have getDeclaration
return a Function instead of a Constant.
llvm-svn: 34008
|
| |
|
|
| |
llvm-svn: 33966
|
| |
|
|
| |
llvm-svn: 33962
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
|