History log of /external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
cd81d94322a39503e4a3e87b6ee03d4fcb3465fb 21-Jul-2014 Stephen Hines <srhines@google.com> Update LLVM for rebase to r212749.

Includes a cherry-pick of:
r212948 - fixes a small issue with atomic calls

Change-Id: Ib97bd980b59f18142a69506400911a6009d9df18
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
dce4a407a24b04eebc6a376f8e62b41aaa7b071f 29-May-2014 Stephen Hines <srhines@google.com> Update LLVM for 3.5 rebase (r209712).

Change-Id: I149556c940fb7dc92d075273c87ff584f400941f
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
36b56886974eae4f9c5ebc96befd3e7bfe5de338 24-Apr-2014 Stephen Hines <srhines@google.com> Update to LLVM 3.5a.

Change-Id: Ifadecab779f128e62e430c2b4f6ddd84953ed617
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
c8dc96be28fd1a3d6ddebbb48b8d55b61e4bd89b 17-Nov-2013 Hal Finkel <hfinkel@anl.gov> Add a loop rerolling flag to the PassManagerBuilder

This adds a boolean member variable to the PassManagerBuilder to control loop
rerolling (just like we have for unrolling and the various vectorization
options). This is necessary for control by the frontend. Loop rerolling remains
disabled by default at all optimization levels.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194966 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
bebe48dbfe00078329341945bfb11f778ace6d12 17-Nov-2013 Hal Finkel <hfinkel@anl.gov> Add a loop rerolling pass

This adds a loop rerolling pass: the opposite of (partial) loop unrolling. The
transformation aims to take loops like this:

for (int i = 0; i < 3200; i += 5) {
a[i] += alpha * b[i];
a[i + 1] += alpha * b[i + 1];
a[i + 2] += alpha * b[i + 2];
a[i + 3] += alpha * b[i + 3];
a[i + 4] += alpha * b[i + 4];
}

and turn them into this:

for (int i = 0; i < 3200; ++i) {
a[i] += alpha * b[i];
}

and loops like this:

for (int i = 0; i < 500; ++i) {
x[3*i] = foo(0);
x[3*i+1] = foo(0);
x[3*i+2] = foo(0);
}

and turn them into this:

for (int i = 0; i < 1500; ++i) {
x[i] = foo(0);
}

There are two motivations for this transformation:

1. Code-size reduction (especially relevant, obviously, when compiling for
code size).

2. Providing greater choice to the loop vectorizer (and generic unroller) to
choose the unrolling factor (and a better ability to vectorize). The loop
vectorizer can take vector lengths and register pressure into account when
choosing an unrolling factor, for example, and a pre-unrolled loop limits that
choice. This is especially problematic if the manual unrolling was optimized
for a machine different from the current target.

The current implementation is limited to single basic-block loops only. The
rerolling recognition should work regardless of how the loop iterations are
intermixed within the loop body (subject to dependency and side-effect
constraints), but the significant restriction is that the order of the
instructions in each iteration must be identical. This seems sufficient to
capture all current use cases.

This pass is not currently enabled by default at any optimization level.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194939 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
7e667c56cf7e27ff521ceb86518beab32bfb630d 31-Oct-2013 Rafael Espindola <rafael.espindola@gmail.com> Use LTO_SYMBOL_SCOPE_DEFAULT_CAN_BE_HIDDEN instead of the "dso list".

There are two ways one could implement hiding of linkonce_odr symbols in LTO:
* LLVM tells the linker which symbols can be hidden if not used from native
files.
* The linker tells LLVM which symbols are not used from other object files,
but will be put in the dso symbol table if present.

GOLD's API is the second option. It was implemented almost 1:1 in llvm by
passing the list down to internalize.

LLVM already had partial support for the first option. It is also very similar
to how ld64 handles hiding these symbols when *not* doing LTO.

This patch then
* removes the APIs for the DSO list.
* marks LTO_SYMBOL_SCOPE_DEFAULT_CAN_BE_HIDDEN all linkonce_odr unnamed_addr
global values and other linkonce_odr whose address is not used.
* makes the gold plugin responsible for handling the API mismatch.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193800 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
fe16848601bdde6e3a5e0860199169dd171222a4 19-Oct-2013 Nadav Rotem <nrotem@apple.com> Mark some command line flags as hidden

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193013 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
438900938c3ac9d7fac2dd5d2c85ca4b9b2e35f7 03-Oct-2013 Rafael Espindola <rafael.espindola@gmail.com> Optimize linkonce_odr unnamed_addr functions during LTO.

Generalize the API so we can distinguish symbols that are needed just for a DSO
symbol table from those that are used from some native .o.

The symbols that are only wanted for the dso symbol table can be dropped if
llvm can prove every other dso has a copy (linkonce_odr) and the address is not
important (unnamed_addr).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191922 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
7b15c0afc1403c451e32d6ae4ecc43a83af496be 03-Sep-2013 Nadav Rotem <nrotem@apple.com> Enable late-vectorization by default.
This patch changes the default setting for the LateVectorization flag that controls where the loop-vectorizer is ran.

Perf gains:
SingleSource/Benchmarks/Shootout/matrix -37.33%
MultiSource/Benchmarks/PAQ8p/paq8p -22.83%
SingleSource/Benchmarks/Linpack/linpack-pc -16.22%
SingleSource/Benchmarks/Shootout-C++/ary3 -15.16%
MultiSource/Benchmarks/TSVC/NodeSplitting-flt/NodeSplitting-flt -10.34%
MultiSource/Benchmarks/TSVC/NodeSplitting-dbl/NodeSplitting-dbl -7.12%

Regressions:
SingleSource/Benchmarks/Misc/lowercase 15.10%
MultiSource/Benchmarks/TSVC/Equivalencing-flt/Equivalencing-flt 13.18%
SingleSource/Benchmarks/Shootout-C++/matrix 8.27%
SingleSource/Benchmarks/CoyoteBench/lpbench 7.30%



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189858 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
6e4d93b2325b268d5394b82201c1a782cca78fae 30-Aug-2013 Bill Wendling <isanbard@gmail.com> Random cleanup: No need to use a std::vector here, since createInternalizePass uses an ArrayRef.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189632 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
f1cd7983b195b2ab9c106c88b4da82983fe63f92 29-Aug-2013 Nadav Rotem <nrotem@apple.com> Vectorizer/PassManager: I am working on moving the vectorizer out of the SCC passes. This patch moves the SLP-vectorizer and BB-vectorizer back into SCC passes for two reasons:
1. They are a kind of cannonicalization.
2. The performance measurements show that it is better to keep them in.

There should be no functional change if you are not enabling the LateVectorization mode.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189539 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
435798e96a64738b55a01055dde1bc9a88a15191 28-Aug-2013 Hal Finkel <hfinkel@anl.gov> Disable unrolling in the loop vectorizer when disabled in the pass manager

When unrolling is disabled in the pass manager, the loop vectorizer should also
not unroll loops. This will allow the -fno-unroll-loops option in Clang to
behave as expected (even for vectorizable loops). The loop vectorizer's
-force-vector-unroll option will (continue to) override the pass-manager
setting (including -force-vector-unroll=0 to force use of the internal
auto-selection logic).

In order to test this, I added a flag to opt (-disable-loop-unrolling) to force
disable unrolling through opt (the analog of -fno-unroll-loops in Clang). Also,
this fixes a small bug in opt where the loop vectorizer was enabled only after
the pass manager populated the queue of passes (the global_alias.ll test needed
a slight update to the RUN line as a result of this fix).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189499 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
ceda68fe2430e0e3c8bec5487d66881f34b275ed 13-Aug-2013 Arnold Schwaighofer <aschwaighofer@apple.com> Also remove logic in LateVectorize

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188285 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
b6171c529670e5c240aaf9c08f5f1b6dba9d16fc 13-Aug-2013 Arnold Schwaighofer <aschwaighofer@apple.com> Remove logic that decides whether to vectorize or not depending on O-levels

I have moved this logic into clang and opt.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188281 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
01d7203ef8316fdd71c3cec59f8e68fb869e0dbf 06-Aug-2013 Tom Stellard <thomas.stellard@amd.com> Factor FlattenCFG out from SimplifyCFG

Patch by: Mei Ye

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187764 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
72bc423e7f88808f562798504f8405eee625f272 02-Aug-2013 Nadav Rotem <nrotem@apple.com> Move the optlevel check to the frontend.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187628 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
a4cbd78af84b76f92202f2f2b1a3c49ff1f85798 01-Aug-2013 Nadav Rotem <nrotem@apple.com> Only enable SLP-vectorization on O3 builds.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187595 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
57e6b2d1f3de0bf459e96f7038e692d624f7e580 27-Jul-2013 Tom Stellard <thomas.stellard@amd.com> SimplifyCFG: Use parallel-and and parallel-or mode to consolidate branch conditions

Merge consecutive if-regions if they contain identical statements.
Both transformations reduce number of branches. The transformation
is guarded by a target-hook, and is currently enabled only for +R600,
but the correctness has been tested on X86 target using a variety of
CPU benchmarks.

Patch by: Mei Ye

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187278 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
6bf3a05235effa06b10196ee9ebeffee14d886ee 24-Jun-2013 Chandler Carruth <chandlerc@gmail.com> Add a flag to defer vectorization into a phase after the inliner and its
CGSCC pass manager. This should insulate the inlining decisions from the
vectorization decisions, however it may have both compile time and code
size problems so it is just an experimental option right now.

Adding this based on a discussion with Arnold and it seems at least
worth having this flag for us to both run some experiments to see if
this strategy is workable. It may solve some of the regressions seen
with the loop vectorizer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184698 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
be87bce32bc9af9bc5918a6e08806b61e3088165 20-Jun-2013 Meador Inge <meadori@codesourcery.com> Remove the simplify-libcalls pass (finally)

This commit completely removes what is left of the simplify-libcalls
pass. All of the functionality has now been migrated to the instcombine
and functionattrs passes. The following C API functions are now NOPs:

1. LLVMAddSimplifyLibCallsPass
2. LLVMPassManagerBuilderSetDisableSimplifyLibCalls

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184459 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
7459ff4be22e92efdd89884a7c2a0ca63904998d 17-Jun-2013 Nadav Rotem <nrotem@apple.com> Disable vectorization for -Oz.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184089 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
f9f86812865b941e0dd2855318d138e8935792cc 17-Jun-2013 Nadav Rotem <nrotem@apple.com> Enable the loop vectorizer by default for -Os and -O2.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184084 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
9342b9ccdd3f99ad76cdcb03b4c6f557517dd0d8 07-Jun-2013 Nadav Rotem <nrotem@apple.com> Jeffrey Yasskin volunteered to benchmark the vectorizer on -O2 or -Os when compiling chrome. This patch adds a new flag to enable vectorization on all levels and not only on -O3. It should go away once we make a decision.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183456 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
40be1e85665d10f5444186f0e7106e368dd735b8 01-May-2013 Filip Pizlo <fpizlo@apple.com> This patch breaks up Wrap.h so that it does not have to include all of
the things, and renames it to CBindingWrapping.h. I also moved
CBindingWrapping.h into Support/.

This new file just contains the macros for defining different wrap/unwrap
methods.

The calls to those macros, as well as any custom wrap/unwrap definitions
(like for array of Values for example), are put into corresponding C++
headers.

Doing this required some #include surgery, since some .cpp files relied
on the fact that including Wrap.h implicitly caused the inclusion of a
bunch of other things.

This also now means that the C++ headers will include their corresponding
C API headers; for example Value.h must include llvm-c/Core.h. I think
this is harmless, since the C API headers contain just external function
declarations and some C types, so I don't believe there should be any
nasty dependency issues here.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180881 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
3e39731e88f2d4f597cebc74388fd6650ca4f604 23-Apr-2013 Eric Christopher <echristo@gmail.com> Move C++ code out of the C headers and into either C++ headers
or the C++ files themselves. This enables people to use
just a C compiler to interoperate with LLVM.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180063 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
e9a4411db4d3a05965630f668daf8071bf2d3513 16-Apr-2013 Nadav Rotem <nrotem@apple.com> SLPVectorizer: Make it a function pass and add code for hoisting the vector-gather sequence out of loops.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179562 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
1129a832e6ef5291b0144e9f22c76b2599cd5587 15-Apr-2013 Nadav Rotem <nrotem@apple.com> Add an option -vectorize-slp-aggressive for running the BB vectorizer. Make -fslp-vectorize run the slp-vectorizer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179508 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
8849838965941919257b923f8603ca1bacd3fa46 15-Apr-2013 Nadav Rotem <nrotem@apple.com> Rename the slp-vectorizer clang/llvm flags. No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179505 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
0ebc084132cbf4ebebdb6c931ef42f97e3ff5fe1 10-Mar-2013 Nick Lewycky <nicholas@mxc.ca> Use LLVMBool instead of 'bool' in the C API. Based on a patch by Peter Zotov!


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176793 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
76c25dc2bf23b0c710d896ca61f236fe5b18ee08 06-Mar-2013 Andrew Trick <atrick@apple.com> Generalize my previous fix for -print-options.

Always print options that differ from their implicit default. At least
for simple option types.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176572 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
122136b1194fb770f9791f3fea2ef3116e78f504 06-Mar-2013 Andrew Trick <atrick@apple.com> Give -loop-vectorize an explicit default.

This way, clang -mllvm -print-options shows that the driver is overriding it.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176569 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
c0b3d4c9c252acec01de719d4e756456d5377e6d 29-Jan-2013 Hal Finkel <hfinkel@anl.gov> Unroll again after running BBVectorize

Because BBVectorize may significantly shorten a loop body, unroll
again after vectorization. This is especially important when using
runtime or partial unrolling.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173730 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
1ada2ada3cb145861599d349ba372bfc39b20c1d 07-Jan-2013 Chandler Carruth <chandlerc@gmail.com> Remove the long defunct 'DefaultPasses' header. We have a pass manager
builder these days, and this thing hasn't seen updates for a very long
time.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171741 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
b7c772922e53a2b4705fe93397dfbc92d1dc8ef7 04-Jan-2013 Nadav Rotem <nrotem@apple.com> Move the loop vectorizer from O2 to O3. It looks like the increase in code size actually hurts the performance on many programs.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171471 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
38b06020dbd804f01ee3802779a52c05cffdf87d 21-Dec-2012 Roman Divacky <rdivacky@freebsd.org> Remove duplicate includes.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170902 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
62570c2813702814f9d7450ac4c4df065b8b6ccc 19-Dec-2012 Nadav Rotem <nrotem@apple.com> Enable the loop vectorizer in clang and not in the pass manager, so that we can disable it in clang.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170470 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
04b116e08eefe1ddd4a719889f136c624ee5914e 18-Dec-2012 Nadav Rotem <nrotem@apple.com> Enable the loop vectorizer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170416 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
0005093db659ec3d629cdfc014e7f979ad0bb7b8 15-Dec-2012 NAKAMURA Takumi <geek4civic@gmail.com> Revert r170246, "Enable the loop vectorizer by default."

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170267 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
f53e7cb9b95677dcc2181485fed8cb592056b805 14-Dec-2012 Nadav Rotem <nrotem@apple.com> Enable the loop vectorizer by default.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170246 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
31bc9e00d1025186484473ad7e566fbeb7c90a8a 14-Dec-2012 Nadav Rotem <nrotem@apple.com> revert r170166 - disable the loop vectorizer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170172 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
44a71c4575956ce1727df2e1d2fc03fce87fd11b 14-Dec-2012 Nadav Rotem <nrotem@apple.com> Enable the loop vectorizer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170166 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
a97fd7f1a8d5eccdd6b2fb13110de158ea50be5d 14-Dec-2012 Nadav Rotem <nrotem@apple.com> Disable the loop vectorizer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170162 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
9ad73e93a51c473a90e010a489a9c7c221112030 14-Dec-2012 Nadav Rotem <nrotem@apple.com> Enable the Loop Vectorizer by default for O2 and O3. Disable if-conversion by default. I plan to revert this patch later today.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170157 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
ae3b652f5cc19d83b6466d4fa70a7d1c7fb6d06c 12-Dec-2012 Nadav Rotem <nrotem@apple.com> LoopVectorizer: Use the "optsize" attribute to decide if we are allowed to increase the function size.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170004 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
5da804150d418b8b4956b84013f8f67df553c543 12-Dec-2012 Nadav Rotem <nrotem@apple.com> LoopVectorizer: When -Os is used, vectorize only loops that dont require a 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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169950 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
9e81a440f5229f13e21031c208fdecbe07b056c7 10-Dec-2012 Nadav Rotem <nrotem@apple.com> Enable the loop vectorizer only on O2 and above. (Still disabled by default)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169774 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
d04a8d4b33ff316ca4cf961e06c9e312eff8e64f 03-Dec-2012 Chandler Carruth <chandlerc@gmail.com> Use the new script to sort the includes of every file under lib.

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. =]

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169131 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
3d1a975026688379fcd69405062abb1826ef5cf9 29-Nov-2012 Nadav Rotem <nrotem@apple.com> No need to run LICM after loop vectorization because we dont generate invariant code any more.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168928 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
79c07d2a36282b09b9c5d0aa65ebf4bff017621b 15-Nov-2012 Dmitri Gribenko <gribozavr@gmail.com> Use empty parens for empty function parameter list instead of '(void)'.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168049 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
9210cc3a173224b40d9fc45b202f52cc7acf5c5a 30-Oct-2012 Nadav Rotem <nrotem@apple.com> 80-col

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167036 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
2459bf24274bf039a72db650ebf38cd66911eafc 29-Oct-2012 Nadav Rotem <nrotem@apple.com> Rename the BB-vectorize flag to match the dragonegg name

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166948 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
d233b78760e481a9602266f8376eb1189c58bc9a 29-Oct-2012 Nadav Rotem <nrotem@apple.com> Change the PassManagerBuilder (used by -O3) loop vectorizer flag from -vectorize to -vectorize-loops because we dont want to share the same flag as the bb-vectorizer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166937 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
e5551ed9cec1ae777c4e4b8852a1d7842c2e1c3d 26-Oct-2012 Rafael Espindola <rafael.espindola@gmail.com> Change the internalize pass to internalize all symbols when given an empty
list of externals. This makes sense since a shared library with no symbols
can still be useful if it has static constructors.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166795 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
c58b799da583697c7056b5a467ffa819d74d2bc3 25-Oct-2012 Nadav Rotem <nrotem@apple.com> revert accidental change

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166643 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
2652c50f74bc4a874c6a2e4b34ff2d52d479183f 25-Oct-2012 Nadav Rotem <nrotem@apple.com> Implement a basic cost model for vector and scalar instructions.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166642 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
63a1eb62e4eef1cbdedce5c60c3e1243a071eba1 18-Oct-2012 Chandler Carruth <chandlerc@gmail.com> Introduce a BarrierNoop pass, a hack designed to allow *some* control
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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166172 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
d15c0c7ac118cb23241b002e7206221283e36e2d 17-Oct-2012 Nadav Rotem <nrotem@apple.com> Add a loop vectorizer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166112 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
1fe4fae463eba5965aa1f98600161ef7de96aaf1 02-Oct-2012 Chandler Carruth <chandlerc@gmail.com> Turn the new SROA pass back on. Let's see if it sticks this time. =]

Again, let me know if anything breaks due to this!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164986 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
f5fdc14df9914969bf56315cd3be8a3b3822a22e 28-Sep-2012 Evan Cheng <evan.cheng@apple.com> GlobalDCE should be run at -O2 / -Os to eliminate unused dtor, etc. rdar://9142819

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164850 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
bfc342d412724c91f87da1c3abdcf8e1dbf2db8c 27-Sep-2012 Nick Lewycky <nicholas@mxc.ca> Disable the new SROA pass to get the tree back in working order. We don't yet
have testcases for the current problems.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164731 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
84d882ee56b76d571971e9f265be1611b1583720 24-Sep-2012 Chandler Carruth <chandlerc@gmail.com> Enable the new SROA pass by default.

Queue the fallout. ;]

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164480 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
e5373b7c3f3ab3567f5b67f8fe8d61a7f22cea23 18-Sep-2012 Benjamin Kramer <benny.kra@googlemail.com> LNT builders have picked up new SROA, disable it to get the remaining builders green again.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164124 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
c370acdf9698b7eee11f3d8e3732f1d72cd25943 18-Sep-2012 Chandler Carruth <chandlerc@gmail.com> Add a major missing piece to the new SROA pass: aggressive splitting of
FCAs. This is essential in order to promote allocas that are used in
struct returns by frontends like Clang. The FCA load would block the
rest of the pass from firing, resulting is significant regressions with
the bullet benchmark in the nightly test suite.

Thanks to Duncan for repeated discussions about how best to do this, and
to both him and Benjamin for review.

This appears to have blocked many places where the pass tries to fire,
and so I'm expect somewhat different results with this fix added.

As with the last big patch, I'm including a change to enable the SROA by
default *temporarily*. Ben is going to remove this as soon as the LNT
bots pick up the patch. I'm just trying to get a round of LNT numbers
from the stable machines in the lab.

NOTE: Four clang tests are expected to fail in the brief window where
this is enabled. Sorry for the noise!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164119 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
8a96348a417acedef5d62eaff5245d31d0efa3f9 15-Sep-2012 Benjamin Kramer <benny.kra@googlemail.com> Disable new sroa now that all buildbots have tested it.

What we have so far:
- Some clang test failures (these were known already)

- Perf results are mixed, some big regressions
http://llvm.org/perf/db_default/v4/nts/3844
http://llvm.org/perf/db_default/v4/nts/3845

bullet suffers a lot. matmul is interesting: slower scalar code, faster with -vectorize.

- Some dragonegg selfhost bots crash in SROA during selfhost now
http://lab.llvm.org:8011/builders/dragonegg-x86_64-linux-gcc-4.6-self-host-checks/builds/1632
http://lab.llvm.org:8011/builders/dragonegg-x86_64-linux-gcc-4.5-self-host/builds/1891

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163968 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
1c8db50a9aca4229ebee75ed9cfbf8b222292787 15-Sep-2012 Chandler Carruth <chandlerc@gmail.com> Port the SSAUpdater-based promotion logic from the old SROA pass to the
new one, and add support for running the new pass in that mode and in
that slot of the pass manager. With this the new pass can completely
replace the old one within the pipeline.

The strategy for enabling or disabling the SSAUpdater logic is to do it
by making the requirement of the domtree analysis optional. By default,
it is required and we get the standard mem2reg approach. This is usually
the desired strategy when run in stand-alone situations. Within the
CGSCC pass manager, we disable requiring of the domtree analysis and
consequentially trigger fallback to the SSAUpdater promotion.

In theory this would allow the pass to re-use a domtree if one happened
to be available even when run in a mode that doesn't require it. In
practice, it lets us have a single pass rather than two which was
simpler for me to wrap my head around.

There is a hidden flag to force the use of the SSAUpdater code path for
the purpose of testing. The primary testing strategy is just to run the
existing tests through that path. One notable difference is that it has
custom code to handle lifetime markers, and one of the tests has been
enhanced to exercise that code.

This has survived a bootstrap and the test suite without serious
correctness issues, however my run of the test suite produced *very*
alarming performance numbers. I don't entirely understand or trust them
though, so more investigation is on-going.

To aid my understanding of the performance impact of the new SROA now
that it runs throughout the optimization pipeline, I'm enabling it by
default in this commit, and will disable it again once the LNT bots have
picked up one iteration with it. I want to get those bots (which are
much more stable) to evaluate the impact of the change before I jump to
any conclusions.

NOTE: Several Clang tests will fail because they run -O3 and check the
result's order of output. They'll go back to passing once I disable it
again.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163965 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
63db8bebe6d4792b2d387a8648409fdd12eb498a 14-Sep-2012 Chandler Carruth <chandlerc@gmail.com> Actually keep the flag default-off for now. =/ That's what I get for
being busy testing this...

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163890 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
713aa9431d84805c5b7ddce57159d14ee94cd548 14-Sep-2012 Chandler Carruth <chandlerc@gmail.com> Introduce a new SROA implementation.

This is essentially a ground up re-think of the SROA pass in LLVM. It
was initially inspired by a few problems with the existing pass:
- It is subject to the bane of my existence in optimizations: arbitrary
thresholds.
- It is overly conservative about which constructs can be split and
promoted.
- The vector value replacement aspect is separated from the splitting
logic, missing many opportunities where splitting and vector value
formation can work together.
- The splitting is entirely based around the underlying type of the
alloca, despite this type often having little to do with the reality
of how that memory is used. This is especially prevelant with unions
and base classes where we tail-pack derived members.
- When splitting fails (often due to the thresholds), the vector value
replacement (again because it is separate) can kick in for
preposterous cases where we simply should have split the value. This
results in forming i1024 and i2048 integer "bit vectors" that
tremendously slow down subsequnet IR optimizations (due to large
APInts) and impede the backend's lowering.

The new design takes an approach that fundamentally is not susceptible
to many of these problems. It is the result of a discusison between
myself and Duncan Sands over IRC about how to premptively avoid these
types of problems and how to do SROA in a more principled way. Since
then, it has evolved and grown, but this remains an important aspect: it
fixes real world problems with the SROA process today.

First, the transform of SROA actually has little to do with replacement.
It has more to do with splitting. The goal is to take an aggregate
alloca and form a composition of scalar allocas which can replace it and
will be most suitable to the eventual replacement by scalar SSA values.
The actual replacement is performed by mem2reg (and in the future
SSAUpdater).

The splitting is divided into four phases. The first phase is an
analysis of the uses of the alloca. This phase recursively walks uses,
building up a dense datastructure representing the ranges of the
alloca's memory actually used and checking for uses which inhibit any
aspects of the transform such as the escape of a pointer.

Once we have a mapping of the ranges of the alloca used by individual
operations, we compute a partitioning of the used ranges. Some uses are
inherently splittable (such as memcpy and memset), while scalar uses are
not splittable. The goal is to build a partitioning that has the minimum
number of splits while placing each unsplittable use in its own
partition. Overlapping unsplittable uses belong to the same partition.
This is the target split of the aggregate alloca, and it maximizes the
number of scalar accesses which become accesses to their own alloca and
candidates for promotion.

Third, we re-walk the uses of the alloca and assign each specific memory
access to all the partitions touched so that we have dense use-lists for
each partition.

Finally, we build a new, smaller alloca for each partition and rewrite
each use of that partition to use the new alloca. During this phase the
pass will also work very hard to transform uses of an alloca into a form
suitable for promotion, including forming vector operations, speculating
loads throguh PHI nodes and selects, etc.

After splitting is complete, each newly refined alloca that is
a candidate for promotion to a scalar SSA value is run through mem2reg.

There are lots of reasonably detailed comments in the source code about
the design and algorithms, and I'm going to be trying to improve them in
subsequent commits to ensure this is well documented, as the new pass is
in many ways more complex than the old one.

Some of this is still a WIP, but the current state is reasonbly stable.
It has passed bootstrap, the nightly test suite, and Duncan has run it
successfully through the ACATS and DragonEgg test suites. That said, it
remains behind a default-off flag until the last few pieces are in
place, and full testing can be done.

Specific areas I'm looking at next:
- Improved comments and some code cleanup from reviews.
- SSAUpdater and enabling this pass inside the CGSCC pass manager.
- Some datastructure tuning and compile-time measurements.
- More aggressive FCA splitting and vector formation.

Many thanks to Duncan Sands for the thorough final review, as well as
Benjamin Kramer for lots of review during the process of writing this
pass, and Daniel Berlin for reviewing the data structures and algorithms
and general theory of the pass. Also, several other people on IRC, over
lunch tables, etc for lots of feedback and advice.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163883 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
064551e94c9763c7e74121b88f9cbccc0969946a 13-Apr-2012 Hal Finkel <hfinkel@anl.gov> By default, use Early-CSE instead of GVN for vectorization cleanup.

As has been suggested by Duncan and others, Early-CSE and GVN should
do similar redundancy elimination, but Early-CSE is much less expensive.
Most of my autovectorization benchmarks show a performance regresion, but
all of these are < 0.1%, and so I think that it is still worth using
the less expensive pass.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154673 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
3197b4453d214aa96de3a42da8f8fe189fff2077 03-Apr-2012 Bill Wendling <isanbard@gmail.com> Add an option to turn off the expensive GVN load PRE part of GVN.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153902 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
1db394921b9635980555cc8d7e0d05b5e885784f 24-Mar-2012 Kostya Serebryany <kcc@google.com> add EP_OptimizerLast extension point

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153353 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
de5e5ec3045a73a06b1054417f9ac6c02929e9ce 01-Feb-2012 Hal Finkel <hfinkel@anl.gov> Add a basic-block autovectorization pass.

This is the initial checkin of the basic-block autovectorization pass along with some supporting vectorization infrastructure.
Special thanks to everyone who helped review this code over the last several months (especially Tobias Grosser).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149468 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
7d4c87ef6eea424b7a28392ea11137ed77b44b57 17-Jan-2012 Dan Gohman <gohman@apple.com> Add a new PassManagerBuilder customization point,
EP_ModuleOptimizerEarly, to allow passes to be added before the
main ModulePass optimizers.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148329 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
0ea3a0c2361e508f07c6c88465799814627ab6cc 07-Dec-2011 Duncan Sands <baldrick@free.fr> Remove unused include.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146037 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
af65a8c54b66e9a78e2c7a9a810a33a73fb7f63a 30-Nov-2011 Kostya Serebryany <kcc@google.com> make asan work at -O0, llvm part. Patch by glider@google.com

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145530 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
7a817eae6cb00a2ba5ec2a4127775b839a357e4c 16-Aug-2011 David Chisnall <csdavec@swan.ac.uk> Add a mechanism for optimisation plugins to register passes that all front ends can use without needing to be aware of the plugin (or the plugin be aware of the front end).

Before 3.0, I'd like to add a mechanism for automatically loading a set of plugins from a config file. API suggestions welcome...



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137717 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
69cb216009387694122c78438a9117f31a2f9ad5 10-Aug-2011 Rafael Espindola <rafael.espindola@gmail.com> Add a C interface to PassManagerBuilder. It is missing the addExtension
functionality since in the C api a pass is created and added to a pass
manager in a single call.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137159 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
c684e83e4554bfaf6180426f86b9253b65dd46ec 02-Aug-2011 Rafael Espindola <rafael.espindola@gmail.com> Move methods in PassManagerBuilder offline.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136727 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp