| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 173454
|
| |
|
|
| |
llvm-svn: 173434
|
| |
|
|
| |
llvm-svn: 173313
|
| |
|
|
| |
llvm-svn: 173311
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
when adding a single attribute to the function.
llvm-svn: 173210
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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.
llvm-svn: 173138
|
| |
|
|
|
|
| |
functional change.
llvm-svn: 173109
|
| |
|
|
| |
llvm-svn: 173108
|
| |
|
|
| |
llvm-svn: 173101
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
We weren't encoding boolean constants correctly due to modeling boolean as a
signed type & then sign extending an i1 up to a byte & getting 255.
llvm-svn: 172926
|
| |
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 172659
|
| |
|
|
| |
llvm-svn: 172615
|
| |
|
|
|
|
|
|
|
|
|
| |
of a class. Emit static data member declarations and definitions
through correctly.
Part of PR14471.
Patch by Paul Robinson!
llvm-svn: 172590
|
| |
|
|
| |
llvm-svn: 172549
|
| |
|
|
|
|
| |
Both underlying IR operations support vectors of pointers already.
llvm-svn: 172538
|
| |
|
|
|
|
|
| |
- Also, update the LangRef documentation on module flags to match the
implementation.
llvm-svn: 172498
|
| |
|
|
|
|
| |
Stop a gcc warning about casting away const.
llvm-svn: 172465
|
| |
|
|
| |
llvm-svn: 172159
|
| |
|
|
|
|
| |
Value's current type. The casting is trivial even for aggregate type.
llvm-svn: 172143
|
| |
|
|
|
|
| |
hangings.
llvm-svn: 172020
|
| |
|
|
| |
llvm-svn: 171960
|
| |
|
|
|
|
|
|
| |
(There already has a concise comment to the declaration.)
Thank Eric Christopher for his feedback!
llvm-svn: 171926
|
| |
|
|
| |
llvm-svn: 171924
|
| |
|
|
|
|
| |
This is causing some problems. The root cause is unknown at this time.
llvm-svn: 171923
|
| |
|
|
|
|
|
| |
- this expression is explicitly marked no-signed-zero, or
- no-signed-zero of this expression can be derived from some context.
llvm-svn: 171922
|
| |
|
|
|
|
| |
make sure that vector types do work.
llvm-svn: 171833
|
| |
|
|
| |
llvm-svn: 171832
|
| |
|
|
| |
llvm-svn: 171826
|
| |
|
|
| |
llvm-svn: 171821
|
| |
|
|
| |
llvm-svn: 171749
|
| |
|
|
|
|
|
|
| |
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 works fine with GDB for member variable pointers, but GDB's support for
member function pointers seems to be quite unrelated to
DW_TAG_ptr_to_member_type. (see GDB bug 14998 for details)
llvm-svn: 171698
|
| |
|
|
|
|
|
| |
This was (somewhat distressingly) only caught be the ocaml bindings
tests...
llvm-svn: 171690
|
| |
|
|
|
|
|
| |
longer would violate any dependency layering and it is in fact an
analysis. =]
llvm-svn: 171686
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a TargetMachine to construct (and thus isn't always available), to an
analysis group that supports layered implementations much like
AliasAnalysis does. This is a pretty massive change, with a few parts
that I was unable to easily separate (sorry), so I'll walk through it.
The first step of this conversion was to make TargetTransformInfo an
analysis group, and to sink the nonce implementations in
ScalarTargetTransformInfo and VectorTargetTranformInfo into
a NoTargetTransformInfo pass. This allows other passes to add a hard
requirement on TTI, and assume they will always get at least on
implementation.
The TargetTransformInfo analysis group leverages the delegation chaining
trick that AliasAnalysis uses, where the base class for the analysis
group delegates to the previous analysis *pass*, allowing all but tho
NoFoo analysis passes to only implement the parts of the interfaces they
support. It also introduces a new trick where each pass in the group
retains a pointer to the top-most pass that has been initialized. This
allows passes to implement one API in terms of another API and benefit
when some other pass above them in the stack has more precise results
for the second API.
The second step of this conversion is to create a pass that implements
the TargetTransformInfo analysis using the target-independent
abstractions in the code generator. This replaces the
ScalarTargetTransformImpl and VectorTargetTransformImpl classes in
lib/Target with a single pass in lib/CodeGen called
BasicTargetTransformInfo. This class actually provides most of the TTI
functionality, basing it upon the TargetLowering abstraction and other
information in the target independent code generator.
The third step of the conversion adds support to all TargetMachines to
register custom analysis passes. This allows building those passes with
access to TargetLowering or other target-specific classes, and it also
allows each target to customize the set of analysis passes desired in
the pass manager. The baseline LLVMTargetMachine implements this
interface to add the BasicTTI pass to the pass manager, and all of the
tools that want to support target-aware TTI passes call this routine on
whatever target machine they end up with to add the appropriate passes.
The fourth step of the conversion created target-specific TTI analysis
passes for the X86 and ARM backends. These passes contain the custom
logic that was previously in their extensions of the
ScalarTargetTransformInfo and VectorTargetTransformInfo interfaces.
I separated them into their own file, as now all of the interface bits
are private and they just expose a function to create the pass itself.
Then I extended these target machines to set up a custom set of analysis
passes, first adding BasicTTI as a fallback, and then adding their
customized TTI implementations.
The fourth step required logic that was shared between the target
independent layer and the specific targets to move to a different
interface, as they no longer derive from each other. As a consequence,
a helper functions were added to TargetLowering representing the common
logic needed both in the target implementation and the codegen
implementation of the TTI pass. While technically this is the only
change that could have been committed separately, it would have been
a nightmare to extract.
The final step of the conversion was just to delete all the old
boilerplate. This got rid of the ScalarTargetTransformInfo and
VectorTargetTransformInfo classes, all of the support in all of the
targets for producing instances of them, and all of the support in the
tools for manually constructing a pass based around them.
Now that TTI is a relatively normal analysis group, two things become
straightforward. First, we can sink it into lib/Analysis which is a more
natural layer for it to live. Second, clients of this interface can
depend on it *always* being available which will simplify their code and
behavior. These (and other) simplifications will follow in subsequent
commits, this one is clearly big enough.
Finally, I'm very aware that much of the comments and documentation
needs to be updated. As soon as I had this working, and plausibly well
commented, I wanted to get it committed and in front of the build bots.
I'll be doing a few passes over documentation later if it sticks.
Commits to update DragonEgg and Clang will be made presently.
llvm-svn: 171681
|
| |
|
|
|
|
|
| |
Based on code review feedback in r171604 from Chandler Carruth &
Eric Christopher.
llvm-svn: 171636
|
| |
|
|
|
|
|
| |
This isn't optimal either but fixes a massive compile time regression from the
attribute uniquing work.
llvm-svn: 171624
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
interfaces which could be extracted from it, and must be provided on
construction, to a chained analysis group.
The end goal here is that TTI works much like AA -- there is a baseline
"no-op" and target independent pass which is in the group, and each
target can expose a target-specific pass in the group. These passes will
naturally chain allowing each target-specific pass to delegate to the
generic pass as needed.
In particular, this will allow a much simpler interface for passes that
would like to use TTI -- they can have a hard dependency on TTI and it
will just be satisfied by the stub implementation when that is all that
is available.
This patch is a WIP however. In particular, the "stub" pass is actually
the one and only pass, and everything there is implemented by delegating
to the target-provided interfaces. As a consequence the tools still have
to explicitly construct the pass. Switching targets to provide custom
passes and sinking the stub behavior into the NoTTI pass is the next
step.
llvm-svn: 171621
|