163 Commits

Author SHA1 Message Date
Sriraman Tallam
f31e663570 [PM] Port CFGViewer and CFGPrinter to the new Pass Manager
Differential Revision: https://reviews.llvm.org/D24592

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281640 91177308-0d34-0410-b5e6-96231b3b80d8
2016-09-15 18:35:27 +00:00
Geoff Berry
aa61209f48 [EarlyCSE] Optionally use MemorySSA. NFC.
Summary:
Use MemorySSA, if requested, to do less conservative memory dependency
checking.

This change doesn't enable the MemorySSA enhanced EarlyCSE in the
default pipelines, so should be NFC.

Reviewers: dberlin, sanjoy, reames, majnemer

Subscribers: mcrosier, llvm-commits

Differential Revision: http://reviews.llvm.org/D19821

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280279 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-31 19:24:10 +00:00
Chandler Carruth
377af8df2b [PM] Introduce basic update capabilities to the new PM's CGSCC pass
manager, including both plumbing and logic to handle function pass
updates.

There are three fundamentally tied changes here:
1) Plumbing *some* mechanism for updating the CGSCC pass manager as the
   CG changes while passes are running.
2) Changing the CGSCC pass manager infrastructure to have support for
   the underlying graph to mutate mid-pass run.
3) Actually updating the CG after function passes run.

I can separate them if necessary, but I think its really useful to have
them together as the needs of  drove , and that in turn drove .

The plumbing technique is to extend the "run" method signature with
extra arguments. We provide the call graph that intrinsically is
available as it is the basis of the pass manager's IR units, and an
output parameter that records the results of updating the call graph
during an SCC passes's run. Note that "...UpdateResult" isn't a *great*
name here... suggestions very welcome.

I tried a pretty frustrating number of different data structures and such
for the innards of the update result. Every other one failed for one
reason or another. Sometimes I just couldn't keep the layers of
complexity right in my head. The thing that really worked was to just
directly provide access to the underlying structures used to walk the
call graph so that their updates could be informed by the *particular*
nature of the change to the graph.

The technique for how to make the pass management infrastructure cope
with mutating graphs was also something that took a really, really large
number of iterations to get to a place where I was happy. Here are some
of the considerations that drove the design:

- We operate at three levels within the infrastructure: RefSCC, SCC, and
  Node. In each case, we are working bottom up and so we want to
  continue to iterate on the "lowest" node as the graph changes. Look at
  how we iterate over nodes in an SCC running function passes as those
  function passes mutate the CG. We continue to iterate on the "lowest"
  SCC, which is the one that continues to contain the function just
  processed.

- The call graph structure re-uses SCCs (and RefSCCs) during mutation
  events for the *highest* entry in the resulting new subgraph, not the
  lowest. This means that it is necessary to continually update the
  current SCC or RefSCC as it shifts. This is really surprising and
  subtle, and took a long time for me to work out. I actually tried
  changing the call graph to provide the opposite behavior, and it
  breaks *EVERYTHING*. The graph update algorithms are really deeply
  tied to this particualr pattern.

- When SCCs or RefSCCs are split apart and refined and we continually
  re-pin our processing to the bottom one in the subgraph, we need to
  enqueue the newly formed SCCs and RefSCCs for subsequent processing.
  Queuing them presents a few challenges:
  1) SCCs and RefSCCs use wildly different iteration strategies at
     a high level. We end up needing to converge them on worklist
     approaches that can be extended in order to be able to handle the
     mutations.
  2) The order of the enqueuing need to remain bottom-up post-order so
     that we don't get surprising order of visitation for things like
     the inliner.
  3) We need the worklists to have set semantics so we don't duplicate
     things endlessly. We don't need a *persistent* set though because
     we always keep processing the bottom node!!!! This is super, super
     surprising to me and took a long time to convince myself this is
     correct, but I'm pretty sure it is... Once we sink down to the
     bottom node, we can't re-split out the same node in any way, and
     the postorder of the current queue is fixed and unchanging.
  4) We need to make sure that the "current" SCC or RefSCC actually gets
     enqueued here such that we re-visit it because we continue
     processing a *new*, *bottom* SCC/RefSCC.

- We also need the ability to *skip* SCCs and RefSCCs that get merged
  into a larger component. We even need the ability to skip *nodes* from
  an SCC that are no longer part of that SCC.

This led to the design you see in the patch which uses SetVector-based
worklists. The RefSCC worklist is always empty until an update occurs
and is just used to handle those RefSCCs created by updates as the
others don't even exist yet and are formed on-demand during the
bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and
we push new SCCs onto it and blacklist existing SCCs on it to get the
desired processing.

We then *directly* update these when updating the call graph as I was
never able to find a satisfactory abstraction around the update
strategy.

Finally, we need to compute the updates for function passes. This is
mostly used as an initial customer of all the update mechanisms to drive
their design to at least cover some real set of use cases. There are
a bunch of interesting things that came out of doing this:

- It is really nice to do this a function at a time because that
  function is likely hot in the cache. This means we want even the
  function pass adaptor to support online updates to the call graph!

- To update the call graph after arbitrary function pass mutations is
  quite hard. We have to build a fairly comprehensive set of
  data structures and then process them. Fortunately, some of this code
  is related to the code for building the cal graph in the first place.
  Unfortunately, very little of it makes any sense to share because the
  nature of what we're doing is so very different. I've factored out the
  one part that made sense at least.

- We need to transfer these updates into the various structures for the
  CGSCC pass manager. Once those were more sanely worked out, this
  became relatively easier. But some of those needs necessitated changes
  to the LazyCallGraph interface to make it significantly easier to
  extract the changed SCCs from an update operation.

- We also need to update the CGSCC analysis manager as the shape of the
  graph changes. When an SCC is merged away we need to clear analyses
  associated with it from the analysis manager which we didn't have
  support for in the analysis manager infrsatructure. New SCCs are easy!
  But then we have the case that the original SCC has its shape changed
  but remains in the call graph. There we need to *invalidate* the
  analyses associated with it.

- We also need to invalidate analyses after we *finish* processing an
  SCC. But the analyses we need to invalidate here are *only those for
  the newly updated SCC*!!! Because we only continue processing the
  bottom SCC, if we split SCCs apart the original one gets invalidated
  once when its shape changes and is not processed farther so its
  analyses will be correct. It is the bottom SCC which continues being
  processed and needs to have the "normal" invalidation done based on
  the preserved analyses set.

All of this is mostly background and context for the changes here.

Many thanks to all the reviewers who helped here. Especially Sanjoy who
caught several interesting bugs in the graph algorithms, David, Sean,
and others who all helped with feedback.

Differential Revision: http://reviews.llvm.org/D21464

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279618 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-24 09:37:14 +00:00
Chandler Carruth
8c28aa1da8 [PM] Re-instate r279227 and r279228 with a fix to the way the templating
was done to hopefully appease MSVC.

As an upside, this also implements the suggestion Sanjoy made in code
review, so two for one! =]

I'll be watching the bots to see if there are still issues.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279295 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-19 18:36:06 +00:00
Chandler Carruth
7d191bbd95 [PM] Revert r279227 and r279228 until I can find someone to help me
solve completely opaque MSVC build errors. It complains about lots of
stuff with this change without givin nearly enough information to even
try to fix.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279231 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-19 10:51:55 +00:00
Chandler Carruth
73e7eb0a79 [PM] Make the the new pass manager support fully generic extra arguments
to run methods, both for transform passes and analysis passes.

This also allows the analysis manager to use a different set of extra
arguments from the pass manager where useful. Consider passes over
analysis produced units of IR like SCCs of the call graph or loops.
Passes of this nature will often want to refer to the analysis result
that was used to compute their IR units (the call graph or LoopInfo).
And for transformations, they may want to communicate special update
information to the outer pass manager. With this change, it becomes
possible to have a run method for a loop pass that looks more like:

  PreservedAnalyses run(Loop &L, AnalysisManager<Loop, LoopInfo> &AM,
                        LoopInfo &LI, LoopUpdateRecord &UR);

And to query the analysis manager like:

    AM.getResult<MyLoopAnalysis>(L, LI);

This makes accessing the known-available analyses convenient and clear,
and it makes passing customized data structures around easy.

My initial use case is going to be in updating the pass manager layers
when the analysis units of IR change. But there are more use cases here
such as having a layer that lets inner passes signal whether certain
additional passes should be run because of particular simplifications
made. Two desires for this have come up in the past: triggering
additional optimization after successfully unrolling loops, and
triggering additional inlining after collapsing indirect calls to direct
calls.

Despite adding this layer of generic extensibility, the *only* change to
existing, simple usage are for places where we forward declare the
AnalysisManager template. We really shouldn't be doing this because of
the fragility exposed here, but currently it makes coping with the
legacy PM code easier.

Differential Revision: http://reviews.llvm.org/D21462

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279227 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-19 09:45:16 +00:00
Chandler Carruth
b699f7b88f [PM] Port the always inliner to the new pass manager in a much more
minimal and boring form than the old pass manager's version.

This pass does the very minimal amount of work necessary to inline
functions declared as always-inline. It doesn't support a wide array of
things that the legacy pass manager did support, but is alse ... about
20 lines of code. So it has that going for it. Notably things this
doesn't support:

- Array alloca merging
  - To support the above, bottom-up inlining with careful history
    tracking and call graph updates
- DCE of the functions that become dead after this inlining.
- Inlining through call instructions with the always_inline attribute.
  Instead, it focuses on inlining functions with that attribute.

The first I've omitted because I'm hoping to just turn it off for the
primary pass manager. If that doesn't pan out, I can add it here but it
will be reasonably expensive to do so.

The second should really be handled by running global-dce after the
inliner. I don't want to re-implement the non-trivial logic necessary to
do comdat-correct DCE of functions. This means the -O0 pipeline will
have to be at least 'always-inline,global-dce', but that seems
reasonable to me. If others are seriously worried about this I'd like to
hear about it and understand why. Again, this is all solveable by
factoring that logic into a utility and calling it here, but I'd like to
wait to do that until there is a clear reason why the existing
pass-based factoring won't work.

The final point is a serious one. I can fairly easily add support for
this, but it seems both costly and a confusing construct for the use
case of the always inliner running at -O0. This attribute can of course
still impact the normal inliner easily (although I find that
a questionable re-use of the same attribute). I've started a discussion
to sort out what semantics we want here and based on that can figure out
if it makes sense ta have this complexity at O0 or not.

One other advantage of this design is that it should be quite a bit
faster due to checking for whether the function is a viable candidate
for inlining exactly once per function instead of doing it for each call
site.

Anyways, hopefully a reasonable starting point for this pass.

Differential Revision: https://reviews.llvm.org/D23299

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278896 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-17 02:56:20 +00:00
Teresa Johnson
f970c6e67b [PM] Port LoopDataPrefetch to new pass manager
Summary:
Refactor the existing support into a LoopDataPrefetch implementation
class and a LoopDataPrefetchLegacyPass class that invokes it.
Add a new LoopDataPrefetchPass for the new pass manager that utilizes
the LoopDataPrefetch implementation class.

Reviewers: mehdi_amini

Subscribers: sanjoy, mzolotukhin, nemanjai, llvm-commits

Differential Revision: https://reviews.llvm.org/D23483

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278591 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-13 04:11:27 +00:00
Michael Kuperstein
69f04075f8 [PM] Port LowerInvoke to the new pass manager
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278531 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-12 17:28:27 +00:00
Teresa Johnson
7be175919a [PM] Port NameAnonFunction pass to new pass manager
Summary:
Port the NameAnonFunction pass and add a test.

Depends on D23439.

Reviewers: mehdi_amini

Subscribers: llvm-commits, mehdi_amini

Differential Revision: https://reviews.llvm.org/D23440

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278509 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-12 14:03:36 +00:00
Teresa Johnson
3143f33d96 [PM] Port ModuleSummaryIndex analysis to new pass manager
Summary:
Port the ModuleSummaryAnalysisWrapperPass to the new pass manager.
Use it in the ported BitcodeWriterPass (similar to how we use the
legacy ModuleSummaryAnalysisWrapperPass in the legacy WriteBitcodePass).

Also, pass the -module-summary opt flag through to the new pass
manager pipeline and through to the bitcode writer pass, and add
a test that uses it.

Reviewers: mehdi_amini

Subscribers: llvm-commits, mehdi_amini

Differential Revision: https://reviews.llvm.org/D23439

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278508 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-12 13:53:02 +00:00
Sean Silva
2058f10aaa Consistently use CGSCCAnalysisManager
Besides a general consistently benefit, the extra layer of indirection
allows the mechanical part of https://reviews.llvm.org/D23256 that
requires touching every transformation and analysis to be factored out
cleanly.

Thanks to David for the suggestion.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278080 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-09 00:28:56 +00:00
Sean Silva
a4f9d70f9b Consistently use LoopAnalysisManager
One exception here is LoopInfo which must forward-declare it (because
the typedef is in LoopPassManager.h which depends on LoopInfo).

Also, some includes for LoopPassManager.h were needed since that file
provides the typedef.

Besides a general consistently benefit, the extra layer of indirection
allows the mechanical part of https://reviews.llvm.org/D23256 that
requires touching every transformation and analysis to be factored out
cleanly.

Thanks to David for the suggestion.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278079 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-09 00:28:52 +00:00
Sean Silva
2fb9a98752 Consistently use ModuleAnalysisManager
Besides a general consistently benefit, the extra layer of indirection
allows the mechanical part of https://reviews.llvm.org/D23256 that
requires touching every transformation and analysis to be factored out
cleanly.

Thanks to David for the suggestion.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278078 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-09 00:28:38 +00:00
Sean Silva
20b343c051 Consistently use FunctionAnalysisManager
Besides a general consistently benefit, the extra layer of indirection
allows the mechanical part of https://reviews.llvm.org/D23256 that
requires touching every transformation and analysis to be factored out
cleanly.

Thanks to David for the suggestion.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278077 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-09 00:28:15 +00:00
Chandler Carruth
411e616ba3 [PM] Change the name of the repeating utility to something less
overloaded (and simpler).

Sean rightly pointed out in code review that we've started using
"wrapper pass" as a specific part of the old pass manager, and in fact
it is more applicable there. Here, we really have a pass *template* to
build a repeated pass, so call it that.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277689 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-04 03:52:53 +00:00
Chandler Carruth
d4bcc6c7a1 [PM] Fix a mis-named parameter in parseLoopPass -- the pass manager was
called "FPM" instead of "LPM" in a hold-over from when the code was
modeled on that used to parse function passes.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277584 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-03 09:14:03 +00:00
Chandler Carruth
91b6bfa061 [PM] Add a generic 'repeat N times' pass wrapper to the new pass
manager.

While this has some utility for debugging and testing on its own, it is
primarily intended to demonstrate the technique for adding custom
wrappers that can provide more interesting interation behavior in
a nice, orthogonal, and composable layer.

Being able to write these kinds of very dynamic and customized controls
for running passes was one of the motivating use cases of the new pass
manager design, and this gives a hint at how they might look. The actual
logic is tiny here, and most of this is just wiring in the pipeline
parsing so that this can be widely used.

I'm adding this now to show the wiring without a lot of business logic.
This is a precursor patch for showing how a "iterate up to N times as
long as we devirtualize a call" utility can be added as a separable and
composable component along side the CGSCC pass management.

Differential Revision: https://reviews.llvm.org/D22405

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277581 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-03 07:44:48 +00:00
Chandler Carruth
0f1f98257c [PM] Remove the NDEBUG condition around isModulePassName.
I forgot to do this initially, and added when I saw this fail in
a no-asserts build, but managed to loose the diff from the actual patch
that got submitted. Very sorry.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277562 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-03 03:26:09 +00:00
Chandler Carruth
3d1a470319 [PM] Significantly refactor the pass pipeline parsing to be easier to
reason about and less error prone.

The core idea is to fully parse the text without trying to identify
passes or structure. This is done with a single state machine. There
were various bugs in the logic around this previously that were repeated
and scattered across the code. Having a single routine makes it much
easier to fix and get correct. For example, this routine doesn't suffer
from PR28577.

Then the actual pass construction is handled using *much* easier to read
code and simple loops, with particular pass manager construction sunk to
live with other pass construction. This is especially nice as the pass
managers *are* in fact passes.

Finally, the "implicit" pass manager synthesis is done much more simply
by forming "pre-parsed" structures rather than having to duplicate tons
of logic.

One of the bugs fixed by this was evident in the tests where we accepted
a pipeline that wasn't really well formed. Another bug is PR28577 for
which I have added a test case.

The code is less efficient than the previous code but I'm really hoping
that's not a priority. ;]

Thanks to Sean for the review!

Differential Revision: https://reviews.llvm.org/D22724

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277561 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-03 03:21:41 +00:00
Michael Kuperstein
3a6d437582 [PM] Port SpeculativeExecution to the new PM
Differential Revision: https://reviews.llvm.org/D23033


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277393 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-01 21:48:33 +00:00
Michael Kuperstein
093715aad1 [PM] Port LowerGuardIntrinsic to the new PM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277057 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-28 22:08:41 +00:00
Michael Kuperstein
b3391842c6 [PM] Port SymbolRewriter to the new PM
Differential Revision: https://reviews.llvm.org/D22703


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276687 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-25 20:52:00 +00:00
Jordan Rose
569213a17c StringSwitch cannot be copied (take 2).
This prevents StringSwitch from being used with 'auto', which is
important because the inferred type is StringSwitch rather than the
result type. This is a problem because StringSwitch stores addresses
of temporary values rather than copying or moving the value into its
own storage.

This is a compromise that still allows wrapping StringSwitch in other
temporary structures, which (unlike StringSwitch) may be non-trivial
to set up and therefore want to at least be movable. (For an example,
see QueryParser.cpp in clang-tools-extra.)

Changing this uncovered the bug in PassBuilder, also in this patch.
Clang doesn't seem to have any occurrences of the issue.

Re-commit of r276652.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276671 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-25 18:34:51 +00:00
Jordan Rose
c0eeb4bf36 Revert "StringSwitch cannot be copied or moved."
This reverts commit r276652. The clang-query tool is currently
relying on this behavior. I'll try again later.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276661 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-25 17:28:33 +00:00
Jordan Rose
04a86972ba StringSwitch cannot be copied or moved.
...but most importantly, it cannot be used well with 'auto', because
the inferred type is StringSwitch rather than the result type. This
is a problem because StringSwitch stores addresses of temporary
values rather than copying or moving the value into its own storage.

Changing this uncovered the bug in PassBuilder, also in this patch.
Clang doesn't seem to have any occurrences of the issue.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276652 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-25 17:08:24 +00:00
Wei Mi
a6c7a032fe [PM] Port BreakCriticalEdges to the new PM.
Differential Revision: https://reviews.llvm.org/D22688


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276449 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-22 18:04:25 +00:00
Wei Mi
3a4fa31d34 [PM] Port NaryReassociate to the new PM
Differential Revision: https://reviews.llvm.org/D22648


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276349 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-21 22:28:52 +00:00
Sean Silva
d8c90ea6b8 [PM] Port LoopUnroll.
We just set PreserveLCSSA to always true since we don't have an
analogous method `mustPreserveAnalysisID(LCSSA)`.

Also port LoopInfo verifier pass to test LoopUnrollPass.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276063 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-19 23:54:23 +00:00
Dehao Chen
e7eb2d5c54 [PM] Convert Loop Strength Reduce pass to new PM
Summary: Convert Loop String Reduce pass to new PM

Reviewers: davidxl, silvas

Subscribers: junbuml, sanjoy, mzolotukhin, llvm-commits

Differential Revision: https://reviews.llvm.org/D22468

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275919 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-18 21:41:50 +00:00
Teresa Johnson
385d70633e [PM] Port FunctionImport Pass to new PM
Summary: Port FunctionImport Pass to new PM.

Reviewers: mehdi_amini, davide

Subscribers: davidxl, llvm-commits

Differential Revision: https://reviews.llvm.org/D22475

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275916 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-18 21:22:24 +00:00
Adam Nemet
9b7ecbef6d [LoopDist] Port to new PM
Summary:
The direct motivation for the port is to ensure that the OptRemarkEmitter
tests work with the new PM.

This remains a function pass because we not only create multiple loops
but could also version the original loop.

In the test I need to invoke opt
with -passes='require<aa>,loop-distribute'.  LoopDistribute does not
directly depend on AA however LAA does.  LAA uses getCachedResult so
I *think* we need manually pull in 'aa'.

Reviewers: davidxl, silvas

Subscribers: sanjoy, llvm-commits, mzolotukhin

Differential Revision: https://reviews.llvm.org/D22437

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275811 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-18 16:29:27 +00:00
Adam Nemet
c7b8b5e22d [OptRemarkEmitter] Port to new PM
Summary:
The main goal is to able to start using the new OptRemarkEmitter
analysis from the LoopVectorizer.  Since the vectorizer was recently
converted to the new PM, it makes sense to convert this analysis as
well.

This pass is currently tested through the LoopDistribution pass, so I am
also porting LoopDistribution to get coverage for this analysis with the
new PM.

Reviewers: davidxl, silvas

Subscribers: llvm-commits, mzolotukhin

Differential Revision: https://reviews.llvm.org/D22436

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275810 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-18 16:29:21 +00:00
Adam Nemet
c476e1701d Sort include headers
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275809 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-18 16:29:17 +00:00
Dehao Chen
78ee4b6ec0 [PM] Convert IVUsers analysis to new pass manager.
Summary: Convert IVUsers analysis to new pass manager.

Reviewers: davidxl, silvas

Subscribers: junbuml, sanjoy, llvm-commits, mzolotukhin

Differential Revision: https://reviews.llvm.org/D22434

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275698 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-16 22:51:33 +00:00
Dehao Chen
ca28eb1502 [PM] Convert LoopInstSimplify Pass to new PM
Summary: Convert LoopInstSimplify to new PM. Unfortunately there is no exisiting unittest for this pass.

Reviewers: davidxl, silvas

Subscribers: silvas, llvm-commits, mzolotukhin

Differential Revision: https://reviews.llvm.org/D22280

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275576 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-15 16:42:11 +00:00
Sebastian Pop
9c2e9dc782 code hoisting pass based on GVN
This pass hoists duplicated computations in the program. The primary goal of
gvn-hoist is to reduce the size of functions before inline heuristics to reduce
the total cost of function inlining.

Pass written by Sebastian Pop, Aditya Kumar, Xiaoyu Hu, and Brian Rzycki.
Important algorithmic contributions by Daniel Berlin under the form of reviews.

Differential Revision: http://reviews.llvm.org/D19338

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275561 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-15 13:45:20 +00:00
Jun Bum Lim
fa907d312a [PM] Port Dead Loop Deletion Pass to the new PM
Summary: Port Dead Loop Deletion Pass to the new pass manager.

Reviewers: silvas, davide

Subscribers: llvm-commits, sanjoy, mcrosier

Differential Revision: https://reviews.llvm.org/D21483

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275453 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-14 18:28:29 +00:00
Nico Weber
037f8a7c73 Revert r275401, it caused PR28551.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275420 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-14 14:41:25 +00:00
Sebastian Pop
16129fc15d code hoisting pass based on GVN
This pass hoists duplicated computations in the program. The primary goal of
gvn-hoist is to reduce the size of functions before inline heuristics to reduce
the total cost of function inlining.

Pass written by Sebastian Pop, Aditya Kumar, Xiaoyu Hu, and Brian Rzycki.
Important algorithmic contributions by Daniel Berlin under the form of reviews.

Differential Revision: http://reviews.llvm.org/D19338

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275401 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-14 12:18:53 +00:00
Dehao Chen
e06fe02dcc Add missing files for r275222
New pass manager for LICM.

Summary: Port LICM to the new pass manager.

Reviewers: davidxl, silvas

Subscribers: krasin, vitalybuka, silvas, davide, sanjoy, llvm-commits, mehdi_amini

Differential Revision: http://reviews.llvm.org/D21772



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275224 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-12 22:42:24 +00:00
Dehao Chen
2ba4d7a7ea [PM] Port LoopIdiomRecognize Pass to new PM
Summary: Port LoopIdiomRecognize Pass to new PM

Reviewers: davidxl

Subscribers: davide, sanjoy, mzolotukhin, llvm-commits

Differential Revision: http://reviews.llvm.org/D22250

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275202 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-12 18:45:51 +00:00
Vitaly Buka
c0c43ac164 Revert "New pass manager for LICM."
Summary: This reverts commit r275118.

Subscribers: sanjoy, mehdi_amini

Differential Revision: http://reviews.llvm.org/D22259

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275156 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-12 06:25:32 +00:00
Dehao Chen
f84fc6de4f New pass manager for LICM.
Summary: Port LICM to the new pass manager.

Reviewers: davidxl, silvas

Subscribers: silvas, davide, sanjoy, llvm-commits, mehdi_amini

Differential Revision: http://reviews.llvm.org/D21772

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275118 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-11 22:45:24 +00:00
Davide Italiano
eb0664013d [PM/IPO] Port LowerTypeTests to the new PassManager.
There's a little bit of churn in this patch because the initialization
mechanism is now shared between the old and the new PM. Other than
that, it's just a pretty mechanical translation.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275082 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-11 18:10:06 +00:00
Sean Silva
89419a6ccc [PM] Port LoopVectorize to the new PM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275000 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-09 22:56:50 +00:00
Davide Italiano
0dd611bd69 [PM] Port CrossDSOCFI to the new pass manager.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274962 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-09 03:25:35 +00:00
Sean Silva
eb2d4257f4 [PM] Fix a think-o. mv {Scalar,Vectorize}/SLPVectorize.h
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274960 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-09 03:11:29 +00:00
Davide Italiano
fff81b23a8 [PM] Port LoopSimplify to the new pass manager.
While here move simplifyLoop() function to the new header, as
suggested by Chandler in the review.

Differential Revision:  http://reviews.llvm.org/D21404

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274959 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-09 03:03:01 +00:00
Xinliang David Li
fd5a3b4bf8 [PM] name the new PM LAA class LoopAccessAnalysis (LAA) /NFC
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274934 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-08 21:21:44 +00:00