Commit Graph

57 Commits

Author SHA1 Message Date
Rafael Espindola
f343bc9956 Use a: and s: instead of a0: and s0: in the DataLayout strings.
They are equivalent and the size of 'a' and 's' is unused.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197259 91177308-0d34-0410-b5e6-96231b3b80d8
2013-12-13 18:56:34 +00:00
NAKAMURA Takumi
3aabdebde2 [CMake] Update LLVM_LINK_COMPONENTS for each CMakeLists.txt.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196908 91177308-0d34-0410-b5e6-96231b3b80d8
2013-12-10 11:13:32 +00:00
Michael Ilseman
faf4d59137 Use present fast-math flags when applicable in CreateBinOp
We were previously not adding fast-math flags through CreateBinOp()
when it happened to be making a floating point binary operator. This
patch updates it to do so similarly to directly calling CreateF*().



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196438 91177308-0d34-0410-b5e6-96231b3b80d8
2013-12-05 00:32:09 +00:00
Diego Novillo
97add46aee Fix dominator descendants for unreachable blocks.
When a block is unreachable, asking its dom tree descendants should
return the empty set. However, the computation of the descendants
was causing a segmentation fault because the dom tree node we get
from the basic block is initially NULL.

Fixed by adding a test for a valid dom tree node before we iterate.

The patch also adds some unit tests to the existing dom tree tests.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196099 91177308-0d34-0410-b5e6-96231b3b80d8
2013-12-02 14:08:27 +00:00
Chandler Carruth
54fec07ec0 [PM] Split the CallGraph out from the ModulePass which creates the
CallGraph.

This makes the CallGraph a totally generic analysis object that is the
container for the graph data structure and the primary interface for
querying and manipulating it. The pass logic is separated into its own
class. For compatibility reasons, the pass provides wrapper methods for
most of the methods on CallGraph -- they all just forward.

This will allow the new pass manager infrastructure to provide its own
analysis pass that constructs the same CallGraph object and makes it
available. The idea is that in the new pass manager, the analysis pass's
'run' method returns a concrete analysis 'result'. Here, that result is
a 'CallGraph'. The 'run' method will typically do only minimal work,
deferring much of the work into the implementation of the result object
in order to be lazy about computing things, but when (like DomTree)
there is *some* up-front computation, the analysis does it prior to
handing the result back to the querying pass.

I know some of this is fairly ugly. I'm happy to change it around if
folks can suggest a cleaner interim state, but there is going to be some
amount of unavoidable ugliness during the transition period. The good
thing is that this is very limited and will naturally go away when the
old pass infrastructure goes away. It won't hang around to bother us
later.

Next up is the initial new-PM-style call graph analysis. =]

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195722 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-26 04:19:30 +00:00
Chandler Carruth
e510665548 [PM] Complete the cross-layer interfaces with a Module-to-Function
proxy. This lets a function pass query a module analysis manager.
However, the interface is const to indicate that only cached results can
be safely queried.

With this, I think the new pass manager is largely functionally complete
for modules and analyses. Still lots to test, and need to generalize to
SCCs and Loops, and need to build an adaptor layer to support the use of
existing Pass objects in the new managers.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195538 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-23 01:25:07 +00:00
Chandler Carruth
2ea1151162 [PM] Rename TestAnalysisPass to TestFunctionAnalysis to clear the way
for a TestModuleAnalysis.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195537 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-23 01:25:02 +00:00
Chandler Carruth
b88831b204 [PM] Add support to the analysis managers to query explicitly for cached
results.

This is the last piece of infrastructure needed to effectively support
querying *up* the analysis layers. The next step will be to introduce
a proxy which provides access to those layers with appropriate use of
const to direct queries to the safe interface.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195525 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-23 00:38:42 +00:00
Chandler Carruth
4d32e85359 [PM] Switch the downward invalidation to be incremental where only the
one function's analyses are invalidated at a time. Also switch the
preservation of the proxy to *fully* preserve the lower (function)
analyses.

Combined, this gets both upward and downward analysis invalidation to
a point I'm happy with:

- A function pass invalidates its function analyses, and its parent's
  module analyses.
- A module pass invalidates all of its functions' analyses including the
  set of which functions are in the module.
- A function pass can preserve a module analysis pass.
- If all function passes preserve a module analysis pass, that
  preservation persists. If any doesn't the module analysis is
  invalidated.
- A module pass can opt into managing *all* function analysis
  invalidation itself or *none*.
- The conservative default is none, and the proxy takes the maximally
  conservative approach that works even if the set of functions has
  changed.
- If a module pass opts into managing function analysis invalidation it
  has to propagate the invalidation itself, the proxy just does nothing.

The only thing really missing is a way to query for a cached analysis or
nothing at all. With this, function passes can more safely request
a cached module analysis pass without fear of it accidentally running
part way through.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195519 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 23:38:07 +00:00
Chandler Carruth
5f347a9bd1 [PM] Teach the analysis managers to pass themselves as arguments to the
run methods of the analysis passes.

Also generalizes and re-uses the SFINAE for transformation passes so
that users can write an analysis pass and only accept an analysis
manager if that is useful to their pass.

This completes the plumbing to make an analysis manager available
through every pass's run method if desired so that passes no longer need
to be constructed around them.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195451 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 12:11:02 +00:00
Chandler Carruth
d984cdc17e [PM] Remove the IRUnitT typedef requirement for analysis passes.
Since the analysis managers were split into explicit function and module
analysis managers, it is now completely trivial to specify this when
building up the concept and model types explicitly, and it is impossible
to end up with a type error at run time. We instantiate a template when
registering a pass that will enforce the requirement at a type-system
level, and we produce a dynamic error on all the other query paths to
the analysis manager if the pass in question isn't registered.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195447 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 11:46:33 +00:00
Chandler Carruth
3f081983cc [PM] Fix the analysis templates' usage of IRUnitT.
This is supposed to be the whole type of the IR unit, and so we
shouldn't pass a pointer to it but rather the value itself. In turn, we
need to provide a 'Module *' as that type argument (for example). This
will become more relevant with SCCs or other units which may not be
passed as a pointer type, but also brings consistency with the
transformation pass templates.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195445 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 11:34:43 +00:00
Chandler Carruth
d793a053ad [PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.

This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.

I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.

Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.

Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:

{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy

(except for XAnalysisManagerXProxy which doesn't make any sense)

This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.

After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
Chandler Carruth
edd2b49134 [PM] Widen the interface for invalidate on an analysis result now that
it is completely optional, and sink the logic for handling the preserved
analysis set into it.

This allows us to implement the delegation logic desired in the proxy
module analysis for the function analysis manager where if the proxy
itself is preserved we assume the set of functions hasn't changed and we
do a fine grained invalidation by walking the functions in the module
and running the invalidate for them all at the manager level and letting
it try to invalidate any passes.

This in turn makes it blindingly obvious why we should hoist the
invalidate trait and have two collections of results. That allows
handling invalidation for almost all analyses without indirect calls and
it allows short circuiting when the preserved set is all.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195338 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-21 10:53:05 +00:00
Chandler Carruth
212226e114 [PM] Add support for using SFINAE to reflect on an analysis's result
type and detect whether or not it provides an 'invalidate' member the
analysis manager should use.

This lets the overwhelming common case of *not* caring about custom
behavior when an analysis is invalidated be the the obvious default
behavior with no code written by the author of an analysis. Only when
they write code specifically to handle invalidation does it get used.

Both cases are actually covered by tests here. The test analysis uses
the default behavior, and the proxy module analysis actually has custom
behavior on invalidation that is firing correctly. (In fact, this is the
analysis which was the primary motivation for having custom invalidation
behavior in the first place.)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195332 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-21 09:10:21 +00:00
Chandler Carruth
7fac06c423 [PM] Add a module analysis pass proxy for the function analysis manager.
This proxy will fill the role of proxying invalidation events down IR
unit layers so that when a module changes we correctly invalidate
function analyses. Currently this is a very coarse solution -- any
change blows away the entire thing -- but the next step is to make
invalidation handling more nuanced so that we can propagate specific
amounts of invalidation from one layer to the next.

The test is extended to place a module pass between two function pass
managers each of which have preserved function analyses which get
correctly invalidated by the module pass that might have changed what
functions are even in the module.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195304 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-21 02:11:31 +00:00
Chandler Carruth
c49e7e6aee [PM] Add the preservation system to the new pass manager.
This adds a new set-like type which represents a set of preserved
analysis passes. The set is managed via the opaque PassT::ID() void*s.
The expected convenience templates for interacting with specific passes
are provided. It also supports a symbolic "all" state which is
represented by an invalid pointer in the set. This state is nicely
saturating as it comes up often. Finally, it supports intersection which
is used when finding the set of preserved passes after N different
transforms.

The pass API is then changed to return the preserved set rather than
a bool. This is much more self-documenting than the previous system.
Returning "none" is a conservatively correct solution just like
returning "true" from todays passes and not marking any passes as
preserved. Passes can also be dynamically preserved or not throughout
the run of the pass, and whatever gets returned is the binding state.
Finally, preserving "all" the passes is allowed for no-op transforms
that simply can't harm such things.

Finally, the analysis managers are changed to instead of blindly
invalidating all of the analyses, invalidate those which were not
preserved. This should rig up all of the basic preservation
functionality. This also correctly combines the preservation moving up
from one IR-layer to the another and the preservation aggregation across
N pass runs. Still to go is incrementally correct invalidation and
preservation across IR layers incrementally during N pass runs. That
will wait until we have a device for even exposing analyses across IR
layers.

While the core of this change is obvious, I'm not happy with the current
testing, so will improve it to cover at least some of the invalidation
that I can test easily in a subsequent commit.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195241 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 11:31:50 +00:00
Chandler Carruth
d14894059f [PM] Make the function pass manager more regular.
The FunctionPassManager is now itself a function pass. When run over
a function, it runs all N of its passes over that function. This is the
1:N mapping in the pass dimension only. This allows it to be used in
either a ModulePassManager or potentially some other manager that
works on IR units which are supersets of Functions.

This commit also adds the obvious adaptor to map from a module pass to
a function pass, running the function pass across every function in the
module.

The test has been updated to use this new pattern.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195192 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:39:16 +00:00
Chandler Carruth
523d929368 [PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.

After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.

As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.

This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
Chandler Carruth
8417e85781 [PM] Completely remove support for explicit 'require' methods on the
AnalysisManager. All this method did was assert something and we have
a perfectly good way to trigger that assert from the query path.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194947 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-17 03:18:05 +00:00
Benjamin Kramer
4da02d43b1 Give unit test its own LLVMContext so MDNodes aren't leaked even if we never call llvm_shutdown.
Found by valgrind.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194797 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-15 09:34:33 +00:00
Matt Arsenault
59d3ae6cdc Add addrspacecast instruction.
Patch by Michele Scandale!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194760 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-15 01:34:59 +00:00
Chandler Carruth
f348c9782c Introduce an AnalysisManager which is like a pass manager but with a lot
more smarts in it. This is where most of the interesting logic that used
to live in the implicit-scheduling-hackery of the old pass manager will
live.

Like the previous commits, note that this is a very early prototype!
I expect substantial changes before this is ready to use.

The core of the design is the following:

- We have an AnalysisManager which can be used across a series of
  passes over a module.
- The code setting up a pass pipeline registers the analyses available
  with the manager.
- Individual transform passes can check than an analysis manager
  provides the analyses they require in order to fail-fast.
- There is *no* implicit registration or scheduling.
- Analysis passes are different from other passes: they produce an
  analysis result that is cached and made available via the analysis
  manager.
- Cached results are invalidated automatically by the pass managers.
- When a transform pass requests an analysis result, either the analysis
  is run to produce the result or a cached result is provided.

There are a few aspects of this design that I *know* will change in
subsequent commits:
- Currently there is no "preservation" system, that needs to be added.
- All of the analysis management should move up to the analysis library.
- The analysis management needs to support at least SCC passes. Maybe
  loop passes. Living in the analysis library will facilitate this.
- Need support for analyses which are *both* module and function passes.
- Need support for pro-actively running module analyses to have cached
  results within a function pass manager.
- Need a clear design for "immutable" passes.
- Need support for requesting cached results when available and not
  re-running the pass even if that would be necessary.
- Need more thorough testing of all of this infrastructure.

There are other aspects that I view as open questions I'm hoping to
resolve as I iterate a bit on the infrastructure, and especially as
I start writing actual passes against this.
- Should we have separate management layers for function, module, and
  SCC analyses? I think "yes", but I'm not yet ready to switch the code.
  Adding SCC support will likely resolve this definitively.
- How should the 'require' functionality work? Should *that* be the only
  way to request results to ensure that passes always require things?
- How should preservation work?
- Probably some other things I'm forgetting. =]

Look forward to more patches in shorter order now that this is in place.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194538 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-13 01:12:08 +00:00
Chandler Carruth
ea9988447c [PM] Start sketching out the new module and function pass manager.
This is still just a skeleton. I'm trying to pull together the
experimentation I've done into committable chunks, and this is the first
coherent one. Others will follow in hopefully short order that move this
more toward a useful initial implementation. I still expect the design
to continue evolving in small ways as I work through the different
requirements and features needed here though.

Keep in mind, all of this is off by default.

Currently, this mostly exercises the use of a polymorphic smart pointer
and templates to hide the polymorphism for the pass manager from the
pass implementation. The next step will be more significant, adding the
first framework of analysis support.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194325 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-09 13:09:08 +00:00
Chandler Carruth
49837ef811 Move the old pass manager infrastructure into a legacy namespace and
give the files a legacy prefix in the right directory. Use forwarding
headers in the old locations to paper over the name change for most
clients during the transitional period.

No functionality changed here! This is just clearing some space to
reduce renaming churn later on with a new system.

Even when the new stuff starts to go in, it is going to be hidden behind
a flag and off-by-default as it is still WIP and under development.

This patch is specifically designed so that very little out-of-tree code
has to change. I'm going to work as hard as I can to keep that the case.
Only direct forward declarations of the PassManager class are impacted
by this change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194324 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-09 12:26:54 +00:00
Rafael Espindola
c143c7573b Merge CallGraph and BasicCallGraph.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193734 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-31 03:03:55 +00:00
Rafael Espindola
415b33f161 Add calls to doInitialization() and doFinalization() in verifyFunction()
The function verifyFunction() in lib/IR/Verifier.cpp misses some
calls. It creates a temporary FunctionPassManager that will run a
single Verifier pass. Unfortunately, FunctionPassManager is no
PassManager and does not call doInitialization() and doFinalization()
by itself. Verifier does important tasks in doInitialization() such as
collecting type information used to check DebugInfo metadata and
doFinalization() does some additional checks. Therefore these checks
were missed and debug info couldn't be verified at all, it just
crashed if the function had some.

verifyFunction() is currently not used in llvm unless -debug option is
enabled, and in unittests/IR/VerifierTest.cpp

VerifierTest had to be changed to create the function in a module from
which the type debug info can be collected.

Patch by Michael Kruse.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193719 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-30 22:37:51 +00:00
Aaron Ballman
bd5b912dcc Silencing an MSVC warning.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192042 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-05 19:41:41 +00:00
Matt Arsenault
2ebcd57e6a Fix getOrInsertGlobal dropping the address space.
Currently it will insert an illegal bitcast.
Arguably, the address space argument should be
added for the creation case.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191702 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-30 21:23:03 +00:00
Benjamin Kramer
adb412daa4 IRBuilder: Add RAII objects to reset insertion points or fast math flags.
Inspired by the object from the SLPVectorizer. This found a minor bug in the
debug loc restoration in the vectorizer where the location of a following
instruction was attached instead of the location from the original instruction.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191673 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-30 15:39:48 +00:00
Bob Wilson
db3a9e64f8 Revert patches to add case-range support for PR1255.
The work on this project was left in an unfinished and inconsistent state.
Hopefully someone will eventually get a chance to implement this feature, but
in the meantime, it is better to put things back the way the were.  I have
left support in the bitcode reader to handle the case-range bitcode format,
so that we do not lose bitcode compatibility with the llvm 3.3 release.

This reverts the following commits: 155464, 156374, 156377, 156613, 156704,
156757, 156804 156808, 156985, 157046, 157112, 157183, 157315, 157384, 157575,
157576, 157586, 157612, 157810, 157814, 157815, 157880, 157881, 157882, 157884,
157887, 157901, 158979, 157987, 157989, 158986, 158997, 159076, 159101, 159100,
159200, 159201, 159207, 159527, 159532, 159540, 159583, 159618, 159658, 159659,
159660, 159661, 159703, 159704, 160076, 167356, 172025, 186736

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190328 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-09 19:14:35 +00:00
Peter Collingbourne
7bba9c5c0a Make one of the AttributeSet ctors maintain the invariant that the
attribute list is ordered by index.

Differential Revision: http://llvm-reviews.chandlerc.com/D1265

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187682 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-02 22:29:40 +00:00
Matt Arsenault
1bf0ec4e16 Fix ptr vector inconsistency in CreatePointerCast
One form would accept a vector of pointers, and the other did not.
Make both accept vectors of pointers, and add an assertion
for the number of elements.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187464 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-31 00:17:33 +00:00
Matt Arsenault
3181f5900f Respect address space sizes in isEliminableCastPair.
This avoids constant folding bitcast/ptrtoint/inttoptr combinations
that have illegal bitcasts between differently sized address spaces.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187455 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-30 22:27:10 +00:00
Matt Arsenault
485c7fd76b Revert "Remove isCastable since nothing uses it now"
Apparently dragonegg uses it.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187454 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-30 22:02:14 +00:00
Matt Arsenault
0de6832c16 Remove isCastable since nothing uses it now
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187448 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-30 21:11:17 +00:00
Matt Arsenault
f34dc428fa Change behavior of calling bitcasted alias functions.
It will now only convert the arguments / return value and call
the underlying function if the types are able to be bitcasted.
This avoids using fp<->int conversions that would occur before.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187444 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-30 20:45:05 +00:00
Matt Arsenault
76bf61fe07 Fix copypaste error in test.
Thename says it's an i32*, but it was actually creating another i8*

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185239 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-28 23:24:10 +00:00
Bill Wendling
ae5758bac7 Add unit test to test a trivial verifier check.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184338 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-19 19:26:44 +00:00
Arnold Schwaighofer
46e7e6f39e Add missing PatternMatch.cpp to CMakeLists.txt
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181147 91177308-0d34-0410-b5e6-96231b3b80d8
2013-05-05 02:14:28 +00:00
Arnold Schwaighofer
e79d92c592 PatternMatch: Matcher for (un)ordered floating point min/max
Add support for matching 'ordered' and 'unordered' floating point min/max
constructs.

In LLVM we can express min/max functions as a combination of compare and select.
We have support for matching such constructs for integers but not for floating
point. In floating point math there is no total order because of the presence of
'NaN'. Therefore, we have to be careful to preserve the original fcmp semantics
when interpreting floating point compare select combinations as a minimum or
maximum function. The resulting 'ordered/unordered' floating point maximum
function has to select the same value as the select/fcmp combination it is based
on.

 ordered_max(x,y)   = max(x,y) iff x and y are not NaN, y otherwise
 unordered_max(x,y) = max(x,y) iff x and y are not NaN, x otherwise
 ordered_min(x,y)   = min(x,y) iff x and y are not NaN, y otherwise
 unordered_min(x,y) = min(x,y) iff x and y are not NaN, x otherwise

This matches the behavior of the underlying select(fcmp(olt/ult/.., L, R), L, R)
construct.

Any code using this predicate has to preserve this semantics.

A follow-up patch will use this to implement floating point min/max reductions
in the vectorizer.

radar://13723044

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181143 91177308-0d34-0410-b5e6-96231b3b80d8
2013-05-05 01:54:46 +00:00
Benjamin Kramer
71c1b22855 Fix a disconcerting bug in Value::isUsedInBasicBlock, which gave wrong answers for blocks larger than 3 instrs.
Also add a unit test. PR15727.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179370 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-12 08:33:11 +00:00
Dan Gohman
a070d2a035 Change GetPointerBaseWithConstantOffset's DataLayout argument from a
reference to a pointer, so that it can handle the case where DataLayout
is not available and behave conservatively.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174024 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-31 02:00:45 +00:00
Bill Wendling
c83f6212a7 Fix test to not use the AttributeSet's AttributeWithIndex creation method.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173608 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-27 03:39:10 +00:00
NAKAMURA Takumi
023d97d703 llvm/unittests: Use OwningPtr to fix --vg-leak.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173240 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-23 08:33:13 +00:00
NAKAMURA Takumi
d422e9f114 IRTests/WaymarkTest.cpp: Fix in --vg-leak.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173239 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-23 08:33:05 +00:00
NAKAMURA Takumi
e82a5fae03 IRTests/IRBuilderTest.cpp: GetIntTy: Delete DL at yourself since it is not linked.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173238 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-23 08:31:28 +00:00
NAKAMURA Takumi
f25b003523 IRTests/IRBuilderTest.cpp: Let GV added to the module.
It fixes --vg-leak.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173237 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-23 08:30:39 +00:00
NAKAMURA Takumi
6bf3e46aa8 IRTests/ConstantsTest.cpp: AsInstructionsTest: Delete each instruction immediately if it is not linked.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173236 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-23 08:30:26 +00:00
NAKAMURA Takumi
bde0f0f225 Untabify.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173235 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-23 08:30:21 +00:00