| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 173738
|
| |
|
|
| |
llvm-svn: 173733
|
| |
|
|
| |
llvm-svn: 173725
|
| |
|
|
|
|
|
| |
The AttributeWithIndex class exposed the interior structure of the AttributeSet
class. That was gross. Remove it and all of the code that relied upon it.
llvm-svn: 173722
|
| |
|
|
| |
llvm-svn: 173661
|
| |
|
|
|
|
|
|
|
|
| |
This now uses the AttributeSet object instead of the Attribute /
AttributeWithIndex objects. It's fairly simple now. It goes through all of the
subsets before the one we're modifying, adds them to the new set. It then adds
the modified subset (with the requested attributes removed). And then adds the
rest of the subsets.
llvm-svn: 173660
|
| |
|
|
|
|
|
|
|
| |
This now uses the AttributeSet object instead of the Attribute /
AttributeWithIndex objects. It's fairly simple now. It goes through all of the
subsets before the one we're modifying, adds them to the new set. It then adds
the modified subset. And then adds the rest of the subsets.
llvm-svn: 173659
|
| |
|
|
|
|
| |
Unfortunately, msvc miscompiles it. Investigating.
llvm-svn: 173656
|
| |
|
|
| |
llvm-svn: 173646
|
| |
|
|
|
|
| |
accessors instead.
llvm-svn: 173644
|
| |
|
|
|
|
| |
accessors instead.
llvm-svn: 173642
|
| |
|
|
|
|
|
|
|
|
| |
We want to remove AttributeWithIndex because it provides a non-encapsulated view
of the AttributeSetImpl object. Instead, use accessor methods and iterators.
Eventually, this code can be simplified because the Attribute object will hold
only one attribute instead of multiple attributes.
llvm-svn: 173641
|
| |
|
|
| |
llvm-svn: 173640
|
| |
|
|
| |
llvm-svn: 173639
|
| |
|
|
|
|
| |
implementation. It in turn uses the correct list for calculating the 'Raw' value.
llvm-svn: 173637
|
| |
|
|
|
|
| |
some random cleanup. No functionality change.
llvm-svn: 173635
|
| |
|
|
| |
llvm-svn: 173628
|
| |
|
|
|
|
| |
Also add some asserts.
llvm-svn: 173627
|
| |
|
|
|
|
| |
attributes being passed in.
llvm-svn: 173618
|
| |
|
|
| |
llvm-svn: 173613
|
| |
|
|
| |
llvm-svn: 173611
|
| |
|
|
|
|
| |
AttributeWithIndex.
llvm-svn: 173536
|
| |
|
|
| |
llvm-svn: 173524
|
| |
|
|
|
|
|
|
| |
The 'getSlot' function and its ilk allow introspection into the AttributeSet
class. However, that class should be opaque. Allow access through accessor
methods instead.
llvm-svn: 173522
|
| |
|
|
| |
llvm-svn: 173499
|
| |
|
|
|
|
| |
AttributeWithIndex.
llvm-svn: 173495
|
| |
|
|
| |
llvm-svn: 173454
|
| |
|
|
| |
llvm-svn: 173313
|
| |
|
|
|
|
|
|
|
|
| |
This is a helper class for the AttributeSetImpl class. It holds a set of
attributes that apply to a single element: function, return type, or
parameter.
These are uniqued.
llvm-svn: 173310
|
| |
|
|
|
|
| |
into the attribute implementation class.
llvm-svn: 173304
|
| |
|
|
| |
llvm-svn: 173302
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SSPStrong applies a heuristic to insert stack protectors in these situations:
* A Protector is required for functions which contain an array, regardless of
type or length.
* A Protector is required for functions which contain a structure/union which
contains an array, regardless of type or length. Note, there is no limit to
the depth of nesting.
* A protector is required when the address of a local variable (i.e., stack
based variable) is exposed. (E.g., such as through a local whose address is
taken as part of the RHS of an assignment or a local whose address is taken as
part of a function argument.)
This patch implements the SSPString attribute to be equivalent to
SSPRequired. This will change in a subsequent patch.
llvm-svn: 173230
|
| |
|
|
|
|
|
|
|
| |
attributes.
Collections of attributes are handled via the AttributeSet class now. This
finally frees us up to make significant changes to how attributes are structured.
llvm-svn: 173228
|
| |
|
|
|
|
| |
when removing one attribute. This further encapsulates the use of the attributes.
llvm-svn: 173214
|
| |
|
|
|
|
|
| |
Use the AttributeSet when we're talking about more than one attribute. Add a
function that adds a single attribute. No functionality change intended.
llvm-svn: 173196
|
| |
|
|
|
|
| |
functional change.
llvm-svn: 173109
|
| |
|
|
| |
llvm-svn: 173108
|
| |
|
|
|
|
|
|
|
| |
Attribute.
This further restricts the use of the Attribute class to the Attribute family of
classes.
llvm-svn: 173098
|
| |
|
|
|
|
|
|
|
| |
Attribute.
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.
llvm-svn: 173094
|
| |
|
|
| |
llvm-svn: 172854
|
| |
|
|
|
|
|
| |
Further encapsulation of the Attribute object. Don't allow direct access to the
Attribute object as an aggregate.
llvm-svn: 172853
|
| |
|
|
|
|
|
|
| |
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.
llvm-svn: 172844
|
| |
|
|
|
|
| |
hangings.
llvm-svn: 172020
|
| |
|
|
| |
llvm-svn: 171960
|
| |
|
|
| |
llvm-svn: 171924
|
| |
|
|
|
|
| |
This is causing some problems. The root cause is unknown at this time.
llvm-svn: 171923
|
| |
|
|
|
|
|
|
| |
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.
llvm-svn: 171712
|
| |
|
|
|
|
|
| |
This isn't optimal either but fixes a massive compile time regression from the
attribute uniquing work.
llvm-svn: 171624
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 171614
|
| |
|
|
|
|
|
|
| |
workaround for gcc-4.4 take #2.
I will investigate, later, what was wrong. I am too tired for now.
llvm-svn: 171611
|