Commit Graph

8 Commits

Author SHA1 Message Date
Amjad Aboud c6483fb873 Another try to commit 323321 (aggressive instruction combine).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@323416 91177308-0d34-0410-b5e6-96231b3b80d8
2018-01-25 12:06:32 +00:00
Amjad Aboud 39319e4065 Reverted 323321.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@323326 91177308-0d34-0410-b5e6-96231b3b80d8
2018-01-24 14:48:49 +00:00
Amjad Aboud 594d89a614 [InstCombine] Introducing Aggressive Instruction Combine pass (-aggressive-instcombine).
Combine expression patterns to form expressions with fewer, simple instructions.
This pass does not modify the CFG.

For example, this pass reduce width of expressions post-dominated by TruncInst
into smaller width when applicable.

It differs from instcombine pass in that it contains pattern optimization that
requires higher complexity than the O(1), thus, it should run fewer times than
instcombine pass.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@323321 91177308-0d34-0410-b5e6-96231b3b80d8
2018-01-24 12:42:42 +00:00
Sanjoy Das b166e6723e (Re-landing) Expose a TargetMachine::getTargetTransformInfo function
Re-land r321234.  It had to be reverted because it broke the shared
library build.  The shared library build broke because there was a
missing LLVMBuild dependency from lib/Passes (which calls
TargetMachine::getTargetIRAnalysis) to lib/Target.  As far as I can
tell, this problem was always there but was somehow masked
before (perhaps because TargetMachine::getTargetIRAnalysis was a
virtual function).

Original commit message:

This makes the TargetMachine interface a bit simpler.  We still need
the std::function in TargetIRAnalysis to avoid having to add a
dependency from Analysis to Target.

See discussion:
http://lists.llvm.org/pipermail/llvm-dev/2017-December/119749.html

I avoided adding all of the backend owners to this review since the
change is simple, but let me know if you feel differently about this.

Reviewers: echristo, MatzeB, hfinkel

Reviewed By: hfinkel

Subscribers: jholewinski, jfb, arsenm, dschuff, mcrosier, sdardis, nemanjai, nhaehnle, javed.absar, sbc100, jgravelle-google, aheejin, kbarton, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321375 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-22 18:21:59 +00:00
Michael Kuperstein 783d353e52 Add missing dependency to LLVMPasses
Passes should depend on CodeGen, as that contains some IR-to-IR passes.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273724 91177308-0d34-0410-b5e6-96231b3b80d8
2016-06-24 21:05:41 +00:00
Marcin Koscielnicki 31068d57c7 Fix shared build of LLVMPasses.
It's missing a dependency on Instrumentation (needed for
llvm::InstrProfiling::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&))

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266656 91177308-0d34-0410-b5e6-96231b3b80d8
2016-04-18 19:04:19 +00:00
Chandler Carruth 896f064a49 [PM/AA] Remove the last relics of the separate IPA library from LLVM,
folding the code into the main Analysis library.

There already wasn't much of a distinction between Analysis and IPA.
A number of the passes in Analysis are actually IPA passes, and there
doesn't seem to be any advantage to separating them.

Moreover, it makes it hard to have interactions between analyses that
are both local and interprocedural. In trying to make the Alias Analysis
infrastructure work with the new pass manager, it becomes particularly
awkward to navigate this split.

I've tried to find all the places where we referenced this, but I may
have missed some. I have also adjusted the C API to continue to be
equivalently functional after this change.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245318 91177308-0d34-0410-b5e6-96231b3b80d8
2015-08-18 17:51:53 +00:00
Chandler Carruth 2349136630 [PM] Create a separate library for high-level pass management code.
This will provide the analogous replacements for the PassManagerBuilder
and other code long term. This code is extracted from the opt tool
currently, and I plan to extend it as I build up support for using the
new pass manager in Clang and other places.

Mailing this out for review in part to let folks comment on the terrible names
here. A brief word about why I chose the names I did.

The library is called "Passes" to try and make it clear that it is a high-level
utility and where *all* of the passes come together and are registered in
a common library. I didn't want it to be *limited* to a registry though, the
registry is just one component.

The class is a "PassBuilder" but this name I'm less happy with. It doesn't
build passes in any traditional sense and isn't a Builder-style API at all. The
class is a PassRegisterer or PassAdder, but neither of those really make a lot
of sense. This class is responsible for constructing passes for registry in an
analysis manager or for population of a pass pipeline. If anyone has a better
name, I would love to hear it. The other candidate I looked at was
PassRegistrar, but that doesn't really fit either. There is no register of all
the passes in use, and so I think continuing the "registry" analog outside of
the registry of pass *names* and *types* is a mistake. The objects themselves
are just objects with the new pass manager.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231556 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-07 09:02:36 +00:00