Use the AttributeSet when we're talking about more than one attribute. Add a
function that adds a single attribute. No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173196 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we tried to infer it from the bit width size, with an added
IsIEEE argument for the PPC/IEEE 128-bit case, which had a default
value. This default value allowed bugs to creep in, where it was
inappropriate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173138 91177308-0d34-0410-b5e6-96231b3b80d8
This is more code to isolate the use of the Attribute class to that of just
holding one attribute instead of a collection of attributes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173094 91177308-0d34-0410-b5e6-96231b3b80d8
I also changed the name of a variable in IRBuilder::CreateFPExtOrFPTrunc to
match the names used in its two matching brethern as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172967 91177308-0d34-0410-b5e6-96231b3b80d8
This implies changing method documentation from the following style:
/// MethodName - Method description...
to
/// \brief Method description...
ala the LLVM Style Guide.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172959 91177308-0d34-0410-b5e6-96231b3b80d8
This method serves an analogous purpose to CreateZExtOrTrunc/CreateSExtOrTrunc
but for floating point types.
In detail, it provides a manner when one is handling conversions of floating
point types of automatically selecting fpext, fptrunc, or identity depending on
the relative bitsize of the source and destination types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172957 91177308-0d34-0410-b5e6-96231b3b80d8
Further encapsulation of the Attribute object. Don't allow direct access to the
Attribute object as an aggregate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172853 91177308-0d34-0410-b5e6-96231b3b80d8
Because the Attribute class is going to stop representing a collection of
attributes, limit the use of it as an aggregate in favor of using AttributeSet.
This replaces some of the uses for querying the function attributes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172844 91177308-0d34-0410-b5e6-96231b3b80d8
- this expression is explicitly marked no-signed-zero, or
- no-signed-zero of this expression can be derived from some context.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171922 91177308-0d34-0410-b5e6-96231b3b80d8
This c'tor takes the AttributeSet class as the parameter. It will eventually
grab the attributes from the specified index and create a new attribute builder
with those attributes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171712 91177308-0d34-0410-b5e6-96231b3b80d8
values -- that's not required to fix the bug that was cropping up, and
the values selected made the enumeration's underlying type signed and
introduced some warnings. This fixes the -Werror build.
The underlying issue here was that the DenseMapInfo was casting values
completely outside the range of the underlying storage of the
enumeration to the enumeration's type. GCC went and "optimized" that
into infloops and other misbehavior. By providing designated special
values for these keys in the dense map, we ensure they are indeed
representable and that they won't be used for anything else.
It might be better to reuse None for the empty key and have the
tombstone share the value of the sentinel enumerator, but honestly
having 2 extra enumerators seemed not to matter and this seems a bit
simpler. I'll let Bill shuffle this around (or ask me to shuffle it
around) if he prefers it to look a different way.
I also made the switch a bit more clear (and produce a better assert)
that the enumerators are *never* going to show up and are errors if they
do.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171614 91177308-0d34-0410-b5e6-96231b3b80d8
The Attribute class is eventually going to represent one attribute. So we need
this class to create the set of attributes. Add some iterator methods to the
builder to access its internal bits in a nice way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171586 91177308-0d34-0410-b5e6-96231b3b80d8
The bit mask thing will be a thing of the past. It's not extensible enough. Get
rid of its use here. Opt instead for using a vector to hold the attributes.
Note: Some of this code will become obsolete once the rewrite is further along.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171553 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove dead methods.
* Use the 'operator==' method instead of 'contains', which isn't needed.
* Fix some comments.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171523 91177308-0d34-0410-b5e6-96231b3b80d8
before the last time.
--- Reverse-merging r171442 into '.':
U include/llvm/IR/Attributes.h
U lib/IR/Attributes.cpp
U lib/IR/AttributeImpl.h
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171448 91177308-0d34-0410-b5e6-96231b3b80d8
The 'operator==' method is a bit clearer and much less verbose for somethings
that should have only one value. Remove from the AttrBuilder for consistency.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171442 91177308-0d34-0410-b5e6-96231b3b80d8
Modify the AttrBuilder class to store the attributes as a set instead of as a
bit mask. The Attribute class will represent only one attribute instead of a
collection of attributes.
This is the wave of the future!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171427 91177308-0d34-0410-b5e6-96231b3b80d8
code that includes Intrinsics.gen directly.
This never showed up in my testing because the old Intrinsics.gen was
still kicking around in the make build system and was correct there. =[
Thankfully, some of the bots to clean rebuilds and that caught this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171373 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171366 91177308-0d34-0410-b5e6-96231b3b80d8
