| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
single attribute in the future.
llvm-svn: 170502
|
|
|
|
|
|
| |
can disable it in clang.
llvm-svn: 170470
|
|
|
|
| |
llvm-svn: 170416
|
|
|
|
| |
llvm-svn: 170267
|
|
|
|
| |
llvm-svn: 170246
|
|
|
|
| |
llvm-svn: 170172
|
|
|
|
| |
llvm-svn: 170166
|
|
|
|
| |
llvm-svn: 170162
|
|
|
|
|
|
| |
by default. I plan to revert this patch later today.
llvm-svn: 170157
|
|
|
|
|
|
|
|
|
| |
Better controls the inlining of functions when the caller function has MinSize attribute.
Basically, when the caller function has this attribute, we do not "force" the inlining
of callee functions carrying the InlineHint attribute (i.e., functions defined with
inline keyword)
llvm-svn: 170065
|
|
|
|
|
|
| |
increase the function size.
llvm-svn: 170004
|
|
|
|
|
|
| |
tail loop. There is no testcase because I dont know of a way to initialize the loop vectorizer pass without adding an additional hidden flag.
llvm-svn: 169950
|
|
|
|
| |
llvm-svn: 169881
|
|
|
|
| |
llvm-svn: 169774
|
|
|
|
|
|
| |
in the near future.
llvm-svn: 169651
|
|
|
|
| |
llvm-svn: 169551
|
|
|
|
| |
llvm-svn: 169550
|
|
|
|
| |
llvm-svn: 169214
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
status.
llvm-svn: 169083
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also check in a case to repeat the issue, on which 'opt -globalopt' consumes 1.6GB memory.
The big memory footprint cause is that current GlobalOpt one by one hoists and stores the leaf element constant into the global array, in each iteration, it recreates the global array initializer constant and leave the old initializer alone. This may result in many obsolete constants left.
For example: we have global array @rom = global [16 x i32] zeroinitializer
After the first element value is hoisted and installed: @rom = global [16 x i32] [ 1, 0, 0, ... ]
After the second element value is installed: @rom = global [16 x 32] [ 1, 2, 0, 0, ... ] // here the previous initializer is obsolete
...
When the transform is done, we have 15 obsolete initializers left useless.
llvm-svn: 169079
|
|
|
|
|
|
| |
invariant code any more.
llvm-svn: 168928
|
|
|
|
|
|
|
|
|
| |
When code deletes the context, the AttributeImpls that the AttrListPtr points to
are now invalid. Therefore, instead of keeping a separate managed static for the
AttrListPtrs that's reference counted, move it into the LLVMContext and delete
it when deleting the AttributeImpls.
llvm-svn: 168354
|
|
|
|
|
|
|
|
|
| |
This patch moves the isInlineViable function from the InlineAlways pass into
the InlineCostAnalyzer and then changes the InlineCost computation to use that
simple check for always-inline functions. All the special-case checks for
AlwaysInline in the CallAnalyzer can then go away.
llvm-svn: 168300
|
|
|
|
| |
llvm-svn: 168049
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For global variables that get the same value stored into them
everywhere, GlobalOpt will replace them with a constant. The problem is
that a thread-local GlobalVariable looks like one value (the address of
the TLS var), but is different between threads.
This patch introduces Constant::isThreadDependent() which returns true
for thread-local variables and constants which depend on them (e.g. a GEP
into a thread-local array), and teaches GlobalOpt not to track such
values.
llvm-svn: 168037
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
getIntPtrType support for multiple address spaces via a pointer type,
and also introduced a crasher bug in the constant folder reported in
PR14233.
These commits also contained several problems that should really be
addressed before they are re-committed. I have avoided reverting various
cleanups to the DataLayout APIs that are reasonable to have moving
forward in order to reduce the amount of churn, and minimize the number
of commits that were reverted. I've also manually updated merge
conflicts and manually arranged for the getIntPtrType function to stay
in DataLayout and to be defined in a plausible way after this revert.
Thanks to Duncan for working through this exact strategy with me, and
Nick Lewycky for tracking down the really annoying crasher this
triggered. (Test case to follow in its own commit.)
After discussing with Duncan extensively, and based on a note from
Micah, I'm going to continue to back out some more of the more
problematic patches in this series in order to ensure we go into the
LLVM 3.2 branch with a reasonable story here. I'll send a note to
llvmdev explaining what's going on and why.
Summary of reverted revisions:
r166634: Fix a compiler warning with an unused variable.
r166607: Add some cleanup to the DataLayout changes requested by
Chandler.
r166596: Revert "Back out r166591, not sure why this made it through
since I cancelled the command. Bleh, sorry about this!
r166591: Delete a directory that wasn't supposed to be checked in yet.
r166578: Add in support for getIntPtrType to get the pointer type based
on the address space.
llvm-svn: 167221
|
|
|
|
|
|
|
|
| |
cheaper.
No functionality change.
llvm-svn: 167116
|
|
|
|
| |
llvm-svn: 167036
|
|
|
|
| |
llvm-svn: 166948
|
|
|
|
|
|
| |
-vectorize to -vectorize-loops because we dont want to share the same flag as the bb-vectorizer.
llvm-svn: 166937
|
|
|
|
|
|
|
| |
split module can see each other. If it is keeping a symbol that already has
a non local linkage, it doesn't need to change it.
llvm-svn: 166908
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
output of both
llvm-extract foo.ll -func=bar
and
llvm-extract foo.ll -func=bar -delete
so the two new files could not be linked together anymore. With this change
alias are handled almost like functions and global variables. Almost because
with alias we cannot just clear the initializer/body, we have to create a new
declaration and replace the alias with it.
The net result is that now the output of the above commands can be linked
even if foo.ll has aliases.
llvm-svn: 166907
|
|
|
|
|
|
|
| |
list of externals. This makes sense since a shared library with no symbols
can still be useful if it has static constructors.
llvm-svn: 166795
|
|
|
|
| |
llvm-svn: 166643
|
|
|
|
| |
llvm-svn: 166642
|
|
|
|
|
|
|
|
|
| |
address space.
This checkin also adds in some tests that utilize these paths and updates some of the
clients.
llvm-svn: 166578
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
over the implicitly-formed-and-nesting CGSCC pass manager and function
pass managers, especially when using them on the opt commandline or
using extension points in the module builder. The '-barrier' opt flag
(or the pass itself) will create a no-op module pass in the pipeline,
resetting the pass manager stack, and allowing the creation of a new
pipeline of function passes or CGSCC passes to be created that is
independent from any previous pipelines.
For example, this can be used to test running two CGSCC passes in
independent CGSCC pass managers as opposed to in the same CGSCC pass
manager. It also allows us to introduce a further hack into the
PassManagerBuilder to separate the O0 pipeline extension passes from the
always-inliner's CGSCC pass manager, which they likely do not want to
participate in... At the very least none of the Sanitizer passes want
this behavior.
This fixes a bug with ASan at O0 currently, and I'll commit the ASan
test which covers this pass. I'm happy to add a test case that this pass
exists and works, but not sure how much time folks would like me to
spend adding test cases for the details of its behavior of partition
pass managers.... The whole thing is just vile, and mostly intended to
unblock ASan, so I'm hoping to rip this all out in a brave new pass
manager world.
llvm-svn: 166172
|
|
|
|
| |
llvm-svn: 166112
|
|
|
|
|
|
| |
simplify the code a bit. No functionality change.
llvm-svn: 166009
|
|
|
|
| |
llvm-svn: 166004
|
|
|
|
|
|
| |
own class named AttrBuilder. No functionality change.
llvm-svn: 165960
|
|
|
|
|
|
| |
This gets rid of some magic numbers.
llvm-svn: 165924
|
|
|
|
|
|
|
|
|
|
| |
Convert the internal representation of the Attributes class into a pointer to an
opaque object that's uniqued by and stored in the LLVMContext object. The
Attributes class then becomes a thin wrapper around this opaque
object. Eventually, the internal representation will be expanded to include
attributes that represent code generation options, etc.
llvm-svn: 165917
|
|
|
|
| |
llvm-svn: 165899
|
|
|
|
|
|
| |
the equivalent from the builder class.
llvm-svn: 165896
|
|
|
|
|
|
| |
it with the equivalent from the builder class.
llvm-svn: 165895
|
|
|
|
|
|
| |
the equivalent from the builder class.
llvm-svn: 165892
|
|
|
|
|
|
|
| |
namespace. Use the attribute's enum value instead. No functionality change
intended.
llvm-svn: 165610
|
|
|
|
|
|
| |
attribute object and add it appropriately. No functionality change.
llvm-svn: 165595
|