| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
caching it. The TLI may change between functions. No functionality change.
llvm-svn: 184349
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OpenBSD's stack smashing protection differs slightly from other
platforms:
1. The smash handler function is "__stack_smash_handler(const char
*funcname)" instead of "__stack_chk_fail(void)".
2. There's a hidden "long __guard_local" object that gets linked
into each executable and DSO.
Patch by Matthew Dempsky.
llvm-svn: 183533
|
|
|
|
| |
llvm-svn: 176467
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The requirements of the strong heuristic are:
* 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.)
llvm-svn: 173231
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
This fixes some of the cycles between libCodeGen and libSelectionDAG. It's still
a complete mess but as long as the edges consist of virtual call it doesn't
cause breakage. BasicTTI did static calls and thus broke some build
configurations.
llvm-svn: 172246
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 171366
|
|
|
|
|
|
|
|
|
| |
directly.
This is in preparation for removing the use of the 'Attribute' class as a
collection of attributes. That will shift to the AttributeSet class instead.
llvm-svn: 171253
|
|
|
|
|
|
| |
single attribute in the future.
llvm-svn: 170502
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
|
|
|
|
|
|
|
| |
We use the enums to query whether an Attributes object has that attribute. The
opaque layer is responsible for knowing where that specific attribute is stored.
llvm-svn: 165488
|
|
|
|
| |
llvm-svn: 165402
|
|
|
|
|
|
|
| |
The hasFnAttr method has been replaced by querying the Attributes explicitly. No
intended functionality change.
llvm-svn: 164725
|
|
|
|
|
|
| |
PR9673
llvm-svn: 162284
|
|
|
|
|
|
| |
<rdar://problem/10545247>
llvm-svn: 162131
|
|
|
|
| |
llvm-svn: 161788
|
|
|
|
|
|
|
| |
character arrays. This is in line with what GCC does.
<rdar://problem/10529227>
llvm-svn: 161446
|
|
|
|
|
|
| |
Patch by Bill Wendling.
llvm-svn: 145097
|
|
|
|
| |
llvm-svn: 135375
|
|
|
|
| |
llvm-svn: 135265
|
|
|
|
| |
llvm-svn: 128465
|
|
|
|
|
|
|
| |
the FailBB dominator is correctly calculated. Believe it or not, there isn't a
functionality change here.
llvm-svn: 128455
|
|
|
|
|
|
| |
dominator information.
llvm-svn: 128452
|
|
|
|
|
|
|
| |
becomes reachable when before it wasn't). Check to make sure that it's not null
before trying to use it.
llvm-svn: 128434
|
|
|
|
|
|
|
| |
protector insertion not working correctly with unreachable code. Since that
revision was rolled out, this test doesn't actual fail before this fix.
llvm-svn: 127497
|
|
|
|
|
|
|
|
|
|
| |
they all ready do). This removes two dominator recomputations prior to isel,
which is a 1% improvement in total llc time for 403.gcc.
The only potentially suspect thing is making GCStrategy recompute dominators if
it used a custom lowering strategy.
llvm-svn: 123064
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
exposes an initializeMyPassFunction(), which
must be called in the pass's constructor. This function uses static dependency declarations to recursively initialize
the pass's dependencies.
Clients that only create passes through the createFooPass() APIs will require no changes. Clients that want to use the
CommandLine options for passes will need to manually call the appropriate initialization functions in PassInitialization.h
before parsing commandline arguments.
I have tested this with all standard configurations of clang and llvm-gcc on Darwin. It is possible that there are problems
with the static dependencies that will only be visible with non-standard options. If you encounter any crash in pass
registration/creation, please send the testcase to me directly.
llvm-svn: 116820
|
|
|
|
| |
llvm-svn: 115996
|
|
|
|
| |
llvm-svn: 110460
|
|
|
|
| |
llvm-svn: 110410
|
|
|
|
|
|
|
|
| |
address of the static
ID member as the sole unique type identifier. Clean up APIs related to this change.
llvm-svn: 110396
|
|
|
|
| |
llvm-svn: 109045
|
|
|
|
| |
llvm-svn: 107670
|
|
|
|
|
|
|
|
|
| |
registers. Split out testcases per architecture and os
now.
Patch from Nelson Elhage.
llvm-svn: 107640
|
|
|
|
|
|
| |
isInteger, we now have isFloatTy and isIntegerTy. Requested by Chris!
llvm-svn: 96223
|
|
|
|
| |
llvm-svn: 92771
|
|
|
|
|
|
|
| |
Chris claims we should never have visibility_hidden inside any .cpp file but
that's still not true even after this commit.
llvm-svn: 85042
|
|
|
|
|
|
| |
does.
llvm-svn: 84916
|
|
|
|
| |
llvm-svn: 78948
|
|
|
|
|
|
| |
AllocaInst and MallocInst.
llvm-svn: 75863
|
|
|
|
| |
llvm-svn: 75703
|
|
|
|
|
|
| |
the [I|F]CmpInst constructors. Who knew!?
llvm-svn: 75200
|
|
|
|
|
|
|
| |
will make it more obvious what it represents, and stop
it being confused with the StoreSize.
llvm-svn: 71349
|
|
|
|
|
|
| |
Delete this default branch, because we're going to generate our own.
llvm-svn: 66234
|
|
|
|
|
|
| |
suggested by Chris.
llvm-svn: 62099
|
|
|
|
| |
llvm-svn: 59519
|
|
|
|
| |
llvm-svn: 59504
|
|
|
|
|
|
|
|
|
| |
- Use less indentation in coding.
- Shorten description.
- Update comments.
- Move code around
llvm-svn: 59496
|
|
|
|
| |
llvm-svn: 59202
|
|
|
|
| |
llvm-svn: 59008
|