[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
//===- BasicTTIImpl.h -------------------------------------------*- C++ -*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
/// \file
|
|
|
|
/// This file provides a helper that implements much of the TTI interface in
|
|
|
|
/// terms of the target-independent code generator and TargetLowering
|
|
|
|
/// interfaces.
|
|
|
|
///
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#ifndef LLVM_CODEGEN_BASICTTIIMPL_H
|
|
|
|
#define LLVM_CODEGEN_BASICTTIIMPL_H
|
|
|
|
|
|
|
|
#include "llvm/Analysis/LoopInfo.h"
|
|
|
|
#include "llvm/Analysis/TargetTransformInfoImpl.h"
|
|
|
|
#include "llvm/Support/CommandLine.h"
|
|
|
|
#include "llvm/Target/TargetLowering.h"
|
|
|
|
#include "llvm/Target/TargetSubtargetInfo.h"
|
2015-03-17 19:26:23 +00:00
|
|
|
#include "llvm/Analysis/TargetLibraryInfo.h"
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
|
|
|
|
namespace llvm {
|
|
|
|
|
|
|
|
extern cl::opt<unsigned> PartialUnrollingThreshold;
|
|
|
|
|
2015-02-01 14:01:15 +00:00
|
|
|
/// \brief Base class which can be used to help build a TTI implementation.
|
|
|
|
///
|
|
|
|
/// This class provides as much implementation of the TTI interface as is
|
|
|
|
/// possible using the target independent parts of the code generator.
|
|
|
|
///
|
2015-02-01 14:22:17 +00:00
|
|
|
/// In order to subclass it, your class must implement a getST() method to
|
|
|
|
/// return the subtarget, and a getTLI() method to return the target lowering.
|
|
|
|
/// We need these methods implemented in the derived class so that this class
|
|
|
|
/// doesn't have to duplicate storage for them.
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
template <typename T>
|
|
|
|
class BasicTTIImplBase : public TargetTransformInfoImplCRTPBase<T> {
|
|
|
|
private:
|
|
|
|
typedef TargetTransformInfoImplCRTPBase<T> BaseT;
|
|
|
|
typedef TargetTransformInfo TTI;
|
|
|
|
|
|
|
|
/// Estimate the overhead of scalarizing an instruction. Insert and Extract
|
|
|
|
/// are set if the result needs to be inserted and/or extracted from vectors.
|
|
|
|
unsigned getScalarizationOverhead(Type *Ty, bool Insert, bool Extract) {
|
|
|
|
assert(Ty->isVectorTy() && "Can only scalarize vectors");
|
|
|
|
unsigned Cost = 0;
|
|
|
|
|
|
|
|
for (int i = 0, e = Ty->getVectorNumElements(); i < e; ++i) {
|
|
|
|
if (Insert)
|
|
|
|
Cost += static_cast<T *>(this)
|
|
|
|
->getVectorInstrCost(Instruction::InsertElement, Ty, i);
|
|
|
|
if (Extract)
|
|
|
|
Cost += static_cast<T *>(this)
|
|
|
|
->getVectorInstrCost(Instruction::ExtractElement, Ty, i);
|
|
|
|
}
|
|
|
|
|
|
|
|
return Cost;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Estimate the cost overhead of SK_Alternate shuffle.
|
|
|
|
unsigned getAltShuffleOverhead(Type *Ty) {
|
|
|
|
assert(Ty->isVectorTy() && "Can only shuffle vectors");
|
|
|
|
unsigned Cost = 0;
|
|
|
|
// Shuffle cost is equal to the cost of extracting element from its argument
|
|
|
|
// plus the cost of inserting them onto the result vector.
|
|
|
|
|
|
|
|
// e.g. <4 x float> has a mask of <0,5,2,7> i.e we need to extract from
|
|
|
|
// index 0 of first vector, index 1 of second vector,index 2 of first
|
|
|
|
// vector and finally index 3 of second vector and insert them at index
|
|
|
|
// <0,1,2,3> of result vector.
|
|
|
|
for (int i = 0, e = Ty->getVectorNumElements(); i < e; ++i) {
|
|
|
|
Cost += static_cast<T *>(this)
|
|
|
|
->getVectorInstrCost(Instruction::InsertElement, Ty, i);
|
|
|
|
Cost += static_cast<T *>(this)
|
|
|
|
->getVectorInstrCost(Instruction::ExtractElement, Ty, i);
|
|
|
|
}
|
|
|
|
return Cost;
|
|
|
|
}
|
|
|
|
|
2015-02-01 14:01:15 +00:00
|
|
|
/// \brief Local query method delegates up to T which *must* implement this!
|
2015-02-01 14:22:17 +00:00
|
|
|
const TargetSubtargetInfo *getST() const {
|
|
|
|
return static_cast<const T *>(this)->getST();
|
2015-02-01 14:01:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief Local query method delegates up to T which *must* implement this!
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
const TargetLoweringBase *getTLI() const {
|
2015-02-01 14:01:15 +00:00
|
|
|
return static_cast<const T *>(this)->getTLI();
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
protected:
|
2015-02-01 13:21:04 +00:00
|
|
|
explicit BasicTTIImplBase(const TargetMachine *TM)
|
2015-02-01 14:01:15 +00:00
|
|
|
: BaseT(TM->getDataLayout()) {}
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
|
|
|
|
public:
|
|
|
|
// Provide value semantics. MSVC requires that we spell all of these out.
|
|
|
|
BasicTTIImplBase(const BasicTTIImplBase &Arg)
|
2015-02-01 14:01:15 +00:00
|
|
|
: BaseT(static_cast<const BaseT &>(Arg)) {}
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
BasicTTIImplBase(BasicTTIImplBase &&Arg)
|
2015-02-01 14:01:15 +00:00
|
|
|
: BaseT(std::move(static_cast<BaseT &>(Arg))) {}
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
BasicTTIImplBase &operator=(const BasicTTIImplBase &RHS) {
|
|
|
|
BaseT::operator=(static_cast<const BaseT &>(RHS));
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
BasicTTIImplBase &operator=(BasicTTIImplBase &&RHS) {
|
|
|
|
BaseT::operator=(std::move(static_cast<BaseT &>(RHS)));
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// \name Scalar TTI Implementations
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
bool hasBranchDivergence() { return false; }
|
|
|
|
|
Divergence analysis for GPU programs
Summary:
Some optimizations such as jump threading and loop unswitching can negatively
affect performance when applied to divergent branches. The divergence analysis
added in this patch conservatively estimates which branches in a GPU program
can diverge. This information can then help LLVM to run certain optimizations
selectively.
Test Plan: test/Analysis/DivergenceAnalysis/NVPTX/diverge.ll
Reviewers: resistor, hfinkel, eliben, meheff, jholewinski
Subscribers: broune, bjarke.roune, madhur13490, tstellarAMD, dberlin, echristo, jholewinski, llvm-commits
Differential Revision: http://reviews.llvm.org/D8576
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234567 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-10 05:03:50 +00:00
|
|
|
bool isSourceOfDivergence(const Value *V) { return false; }
|
|
|
|
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
bool isLegalAddImmediate(int64_t imm) {
|
|
|
|
return getTLI()->isLegalAddImmediate(imm);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool isLegalICmpImmediate(int64_t imm) {
|
|
|
|
return getTLI()->isLegalICmpImmediate(imm);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool isLegalAddressingMode(Type *Ty, GlobalValue *BaseGV, int64_t BaseOffset,
|
2015-06-07 20:12:03 +00:00
|
|
|
bool HasBaseReg, int64_t Scale,
|
|
|
|
unsigned AddrSpace) {
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
TargetLoweringBase::AddrMode AM;
|
|
|
|
AM.BaseGV = BaseGV;
|
|
|
|
AM.BaseOffs = BaseOffset;
|
|
|
|
AM.HasBaseReg = HasBaseReg;
|
|
|
|
AM.Scale = Scale;
|
2015-06-07 20:12:03 +00:00
|
|
|
return getTLI()->isLegalAddressingMode(AM, Ty, AddrSpace);
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
int getScalingFactorCost(Type *Ty, GlobalValue *BaseGV, int64_t BaseOffset,
|
2015-06-07 20:12:03 +00:00
|
|
|
bool HasBaseReg, int64_t Scale, unsigned AddrSpace) {
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
TargetLoweringBase::AddrMode AM;
|
|
|
|
AM.BaseGV = BaseGV;
|
|
|
|
AM.BaseOffs = BaseOffset;
|
|
|
|
AM.HasBaseReg = HasBaseReg;
|
|
|
|
AM.Scale = Scale;
|
2015-06-07 20:12:03 +00:00
|
|
|
return getTLI()->getScalingFactorCost(AM, Ty, AddrSpace);
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
bool isTruncateFree(Type *Ty1, Type *Ty2) {
|
|
|
|
return getTLI()->isTruncateFree(Ty1, Ty2);
|
|
|
|
}
|
|
|
|
|
2015-02-23 19:15:16 +00:00
|
|
|
bool isProfitableToHoist(Instruction *I) {
|
|
|
|
return getTLI()->isProfitableToHoist(I);
|
|
|
|
}
|
|
|
|
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
bool isTypeLegal(Type *Ty) {
|
|
|
|
EVT VT = getTLI()->getValueType(Ty);
|
|
|
|
return getTLI()->isTypeLegal(VT);
|
|
|
|
}
|
|
|
|
|
2015-02-11 14:22:18 +00:00
|
|
|
unsigned getIntrinsicCost(Intrinsic::ID IID, Type *RetTy,
|
|
|
|
ArrayRef<const Value *> Arguments) {
|
|
|
|
return BaseT::getIntrinsicCost(IID, RetTy, Arguments);
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned getIntrinsicCost(Intrinsic::ID IID, Type *RetTy,
|
|
|
|
ArrayRef<Type *> ParamTys) {
|
|
|
|
if (IID == Intrinsic::cttz) {
|
|
|
|
if (getTLI()->isCheapToSpeculateCttz())
|
|
|
|
return TargetTransformInfo::TCC_Basic;
|
|
|
|
return TargetTransformInfo::TCC_Expensive;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (IID == Intrinsic::ctlz) {
|
|
|
|
if (getTLI()->isCheapToSpeculateCtlz())
|
|
|
|
return TargetTransformInfo::TCC_Basic;
|
|
|
|
return TargetTransformInfo::TCC_Expensive;
|
|
|
|
}
|
|
|
|
|
|
|
|
return BaseT::getIntrinsicCost(IID, RetTy, ParamTys);
|
|
|
|
}
|
|
|
|
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
unsigned getJumpBufAlignment() { return getTLI()->getJumpBufAlignment(); }
|
|
|
|
|
|
|
|
unsigned getJumpBufSize() { return getTLI()->getJumpBufSize(); }
|
|
|
|
|
|
|
|
bool shouldBuildLookupTables() {
|
|
|
|
const TargetLoweringBase *TLI = getTLI();
|
|
|
|
return TLI->isOperationLegalOrCustom(ISD::BR_JT, MVT::Other) ||
|
|
|
|
TLI->isOperationLegalOrCustom(ISD::BRIND, MVT::Other);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool haveFastSqrt(Type *Ty) {
|
|
|
|
const TargetLoweringBase *TLI = getTLI();
|
|
|
|
EVT VT = TLI->getValueType(Ty);
|
|
|
|
return TLI->isTypeLegal(VT) &&
|
|
|
|
TLI->isOperationLegalOrCustom(ISD::FSQRT, VT);
|
|
|
|
}
|
|
|
|
|
2015-02-05 02:09:33 +00:00
|
|
|
unsigned getFPOpCost(Type *Ty) {
|
|
|
|
// By default, FP instructions are no more expensive since they are
|
|
|
|
// implemented in HW. Target specific TTI can override this.
|
|
|
|
return TargetTransformInfo::TCC_Basic;
|
|
|
|
}
|
|
|
|
|
2015-02-12 14:17:24 +00:00
|
|
|
unsigned getOperationCost(unsigned Opcode, Type *Ty, Type *OpTy) {
|
|
|
|
const TargetLoweringBase *TLI = getTLI();
|
|
|
|
switch (Opcode) {
|
|
|
|
default: break;
|
|
|
|
case Instruction::Trunc: {
|
|
|
|
if (TLI->isTruncateFree(OpTy, Ty))
|
|
|
|
return TargetTransformInfo::TCC_Free;
|
|
|
|
return TargetTransformInfo::TCC_Basic;
|
|
|
|
}
|
|
|
|
case Instruction::ZExt: {
|
|
|
|
if (TLI->isZExtFree(OpTy, Ty))
|
|
|
|
return TargetTransformInfo::TCC_Free;
|
|
|
|
return TargetTransformInfo::TCC_Basic;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return BaseT::getOperationCost(Opcode, Ty, OpTy);
|
|
|
|
}
|
|
|
|
|
2015-02-01 14:31:23 +00:00
|
|
|
void getUnrollingPreferences(Loop *L, TTI::UnrollingPreferences &UP) {
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
// This unrolling functionality is target independent, but to provide some
|
|
|
|
// motivation for its intended use, for x86:
|
|
|
|
|
|
|
|
// According to the Intel 64 and IA-32 Architectures Optimization Reference
|
|
|
|
// Manual, Intel Core models and later have a loop stream detector (and
|
|
|
|
// associated uop queue) that can benefit from partial unrolling.
|
|
|
|
// The relevant requirements are:
|
|
|
|
// - The loop must have no more than 4 (8 for Nehalem and later) branches
|
|
|
|
// taken, and none of them may be calls.
|
|
|
|
// - The loop can have no more than 18 (28 for Nehalem and later) uops.
|
|
|
|
|
|
|
|
// According to the Software Optimization Guide for AMD Family 15h
|
|
|
|
// Processors, models 30h-4fh (Steamroller and later) have a loop predictor
|
|
|
|
// and loop buffer which can benefit from partial unrolling.
|
|
|
|
// The relevant requirements are:
|
|
|
|
// - The loop must have fewer than 16 branches
|
|
|
|
// - The loop must have less than 40 uops in all executed loop branches
|
|
|
|
|
|
|
|
// The number of taken branches in a loop is hard to estimate here, and
|
|
|
|
// benchmarking has revealed that it is better not to be conservative when
|
|
|
|
// estimating the branch count. As a result, we'll ignore the branch limits
|
|
|
|
// until someone finds a case where it matters in practice.
|
|
|
|
|
|
|
|
unsigned MaxOps;
|
2015-02-01 14:22:17 +00:00
|
|
|
const TargetSubtargetInfo *ST = getST();
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
if (PartialUnrollingThreshold.getNumOccurrences() > 0)
|
|
|
|
MaxOps = PartialUnrollingThreshold;
|
|
|
|
else if (ST->getSchedModel().LoopMicroOpBufferSize > 0)
|
|
|
|
MaxOps = ST->getSchedModel().LoopMicroOpBufferSize;
|
|
|
|
else
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Scan the loop: don't unroll loops with calls.
|
|
|
|
for (Loop::block_iterator I = L->block_begin(), E = L->block_end(); I != E;
|
|
|
|
++I) {
|
|
|
|
BasicBlock *BB = *I;
|
|
|
|
|
|
|
|
for (BasicBlock::iterator J = BB->begin(), JE = BB->end(); J != JE; ++J)
|
|
|
|
if (isa<CallInst>(J) || isa<InvokeInst>(J)) {
|
|
|
|
ImmutableCallSite CS(J);
|
|
|
|
if (const Function *F = CS.getCalledFunction()) {
|
|
|
|
if (!static_cast<T *>(this)->isLoweredToCall(F))
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Enable runtime and partial unrolling up to the specified size.
|
|
|
|
UP.Partial = UP.Runtime = true;
|
|
|
|
UP.PartialThreshold = UP.PartialOptSizeThreshold = MaxOps;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// @}
|
|
|
|
|
|
|
|
/// \name Vector TTI Implementations
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
unsigned getNumberOfRegisters(bool Vector) { return 1; }
|
|
|
|
|
|
|
|
unsigned getRegisterBitWidth(bool Vector) { return 32; }
|
|
|
|
|
2015-05-06 17:12:25 +00:00
|
|
|
unsigned getMaxInterleaveFactor(unsigned VF) { return 1; }
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
|
|
|
|
unsigned getArithmeticInstrCost(
|
|
|
|
unsigned Opcode, Type *Ty,
|
|
|
|
TTI::OperandValueKind Opd1Info = TTI::OK_AnyValue,
|
|
|
|
TTI::OperandValueKind Opd2Info = TTI::OK_AnyValue,
|
|
|
|
TTI::OperandValueProperties Opd1PropInfo = TTI::OP_None,
|
|
|
|
TTI::OperandValueProperties Opd2PropInfo = TTI::OP_None) {
|
|
|
|
// Check if any of the operands are vector operands.
|
|
|
|
const TargetLoweringBase *TLI = getTLI();
|
|
|
|
int ISD = TLI->InstructionOpcodeToISD(Opcode);
|
|
|
|
assert(ISD && "Invalid opcode");
|
|
|
|
|
|
|
|
std::pair<unsigned, MVT> LT = TLI->getTypeLegalizationCost(Ty);
|
|
|
|
|
|
|
|
bool IsFloat = Ty->getScalarType()->isFloatingPointTy();
|
|
|
|
// Assume that floating point arithmetic operations cost twice as much as
|
|
|
|
// integer operations.
|
|
|
|
unsigned OpCost = (IsFloat ? 2 : 1);
|
|
|
|
|
|
|
|
if (TLI->isOperationLegalOrPromote(ISD, LT.second)) {
|
|
|
|
// The operation is legal. Assume it costs 1.
|
|
|
|
// If the type is split to multiple registers, assume that there is some
|
|
|
|
// overhead to this.
|
|
|
|
// TODO: Once we have extract/insert subvector cost we need to use them.
|
|
|
|
if (LT.first > 1)
|
|
|
|
return LT.first * 2 * OpCost;
|
|
|
|
return LT.first * 1 * OpCost;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!TLI->isOperationExpand(ISD, LT.second)) {
|
|
|
|
// If the operation is custom lowered then assume
|
|
|
|
// thare the code is twice as expensive.
|
|
|
|
return LT.first * 2 * OpCost;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Else, assume that we need to scalarize this op.
|
|
|
|
if (Ty->isVectorTy()) {
|
|
|
|
unsigned Num = Ty->getVectorNumElements();
|
|
|
|
unsigned Cost = static_cast<T *>(this)
|
|
|
|
->getArithmeticInstrCost(Opcode, Ty->getScalarType());
|
|
|
|
// return the cost of multiple scalar invocation plus the cost of
|
|
|
|
// inserting
|
|
|
|
// and extracting the values.
|
|
|
|
return getScalarizationOverhead(Ty, true, true) + Num * Cost;
|
|
|
|
}
|
|
|
|
|
|
|
|
// We don't know anything about this scalar instruction.
|
|
|
|
return OpCost;
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned getShuffleCost(TTI::ShuffleKind Kind, Type *Tp, int Index,
|
|
|
|
Type *SubTp) {
|
|
|
|
if (Kind == TTI::SK_Alternate) {
|
|
|
|
return getAltShuffleOverhead(Tp);
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned getCastInstrCost(unsigned Opcode, Type *Dst, Type *Src) {
|
|
|
|
const TargetLoweringBase *TLI = getTLI();
|
|
|
|
int ISD = TLI->InstructionOpcodeToISD(Opcode);
|
|
|
|
assert(ISD && "Invalid opcode");
|
|
|
|
|
|
|
|
std::pair<unsigned, MVT> SrcLT = TLI->getTypeLegalizationCost(Src);
|
|
|
|
std::pair<unsigned, MVT> DstLT = TLI->getTypeLegalizationCost(Dst);
|
|
|
|
|
|
|
|
// Check for NOOP conversions.
|
|
|
|
if (SrcLT.first == DstLT.first &&
|
|
|
|
SrcLT.second.getSizeInBits() == DstLT.second.getSizeInBits()) {
|
|
|
|
|
|
|
|
// Bitcast between types that are legalized to the same type are free.
|
|
|
|
if (Opcode == Instruction::BitCast || Opcode == Instruction::Trunc)
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Opcode == Instruction::Trunc &&
|
|
|
|
TLI->isTruncateFree(SrcLT.second, DstLT.second))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (Opcode == Instruction::ZExt &&
|
|
|
|
TLI->isZExtFree(SrcLT.second, DstLT.second))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
// If the cast is marked as legal (or promote) then assume low cost.
|
|
|
|
if (SrcLT.first == DstLT.first &&
|
|
|
|
TLI->isOperationLegalOrPromote(ISD, DstLT.second))
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
// Handle scalar conversions.
|
|
|
|
if (!Src->isVectorTy() && !Dst->isVectorTy()) {
|
|
|
|
|
|
|
|
// Scalar bitcasts are usually free.
|
|
|
|
if (Opcode == Instruction::BitCast)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
// Just check the op cost. If the operation is legal then assume it costs
|
|
|
|
// 1.
|
|
|
|
if (!TLI->isOperationExpand(ISD, DstLT.second))
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
// Assume that illegal scalar instruction are expensive.
|
|
|
|
return 4;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Check vector-to-vector casts.
|
|
|
|
if (Dst->isVectorTy() && Src->isVectorTy()) {
|
|
|
|
|
|
|
|
// If the cast is between same-sized registers, then the check is simple.
|
|
|
|
if (SrcLT.first == DstLT.first &&
|
|
|
|
SrcLT.second.getSizeInBits() == DstLT.second.getSizeInBits()) {
|
|
|
|
|
|
|
|
// Assume that Zext is done using AND.
|
|
|
|
if (Opcode == Instruction::ZExt)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
// Assume that sext is done using SHL and SRA.
|
|
|
|
if (Opcode == Instruction::SExt)
|
|
|
|
return 2;
|
|
|
|
|
|
|
|
// Just check the op cost. If the operation is legal then assume it
|
|
|
|
// costs
|
|
|
|
// 1 and multiply by the type-legalization overhead.
|
|
|
|
if (!TLI->isOperationExpand(ISD, DstLT.second))
|
|
|
|
return SrcLT.first * 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If we are converting vectors and the operation is illegal, or
|
|
|
|
// if the vectors are legalized to different types, estimate the
|
|
|
|
// scalarization costs.
|
|
|
|
unsigned Num = Dst->getVectorNumElements();
|
|
|
|
unsigned Cost = static_cast<T *>(this)->getCastInstrCost(
|
|
|
|
Opcode, Dst->getScalarType(), Src->getScalarType());
|
|
|
|
|
|
|
|
// Return the cost of multiple scalar invocation plus the cost of
|
|
|
|
// inserting and extracting the values.
|
|
|
|
return getScalarizationOverhead(Dst, true, true) + Num * Cost;
|
|
|
|
}
|
|
|
|
|
|
|
|
// We already handled vector-to-vector and scalar-to-scalar conversions.
|
|
|
|
// This
|
|
|
|
// is where we handle bitcast between vectors and scalars. We need to assume
|
|
|
|
// that the conversion is scalarized in one way or another.
|
|
|
|
if (Opcode == Instruction::BitCast)
|
|
|
|
// Illegal bitcasts are done by storing and loading from a stack slot.
|
|
|
|
return (Src->isVectorTy() ? getScalarizationOverhead(Src, false, true)
|
|
|
|
: 0) +
|
|
|
|
(Dst->isVectorTy() ? getScalarizationOverhead(Dst, true, false)
|
|
|
|
: 0);
|
|
|
|
|
|
|
|
llvm_unreachable("Unhandled cast");
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned getCFInstrCost(unsigned Opcode) {
|
|
|
|
// Branches are assumed to be predicted.
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned getCmpSelInstrCost(unsigned Opcode, Type *ValTy, Type *CondTy) {
|
|
|
|
const TargetLoweringBase *TLI = getTLI();
|
|
|
|
int ISD = TLI->InstructionOpcodeToISD(Opcode);
|
|
|
|
assert(ISD && "Invalid opcode");
|
|
|
|
|
|
|
|
// Selects on vectors are actually vector selects.
|
|
|
|
if (ISD == ISD::SELECT) {
|
|
|
|
assert(CondTy && "CondTy must exist");
|
|
|
|
if (CondTy->isVectorTy())
|
|
|
|
ISD = ISD::VSELECT;
|
|
|
|
}
|
|
|
|
|
|
|
|
std::pair<unsigned, MVT> LT = TLI->getTypeLegalizationCost(ValTy);
|
|
|
|
|
|
|
|
if (!(ValTy->isVectorTy() && !LT.second.isVector()) &&
|
|
|
|
!TLI->isOperationExpand(ISD, LT.second)) {
|
|
|
|
// The operation is legal. Assume it costs 1. Multiply
|
|
|
|
// by the type-legalization overhead.
|
|
|
|
return LT.first * 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Otherwise, assume that the cast is scalarized.
|
|
|
|
if (ValTy->isVectorTy()) {
|
|
|
|
unsigned Num = ValTy->getVectorNumElements();
|
|
|
|
if (CondTy)
|
|
|
|
CondTy = CondTy->getScalarType();
|
|
|
|
unsigned Cost = static_cast<T *>(this)->getCmpSelInstrCost(
|
|
|
|
Opcode, ValTy->getScalarType(), CondTy);
|
|
|
|
|
|
|
|
// Return the cost of multiple scalar invocation plus the cost of
|
|
|
|
// inserting
|
|
|
|
// and extracting the values.
|
|
|
|
return getScalarizationOverhead(ValTy, true, false) + Num * Cost;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Unknown scalar opcode.
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned getVectorInstrCost(unsigned Opcode, Type *Val, unsigned Index) {
|
|
|
|
std::pair<unsigned, MVT> LT =
|
|
|
|
getTLI()->getTypeLegalizationCost(Val->getScalarType());
|
|
|
|
|
|
|
|
return LT.first;
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned getMemoryOpCost(unsigned Opcode, Type *Src, unsigned Alignment,
|
|
|
|
unsigned AddressSpace) {
|
|
|
|
assert(!Src->isVoidTy() && "Invalid type");
|
|
|
|
std::pair<unsigned, MVT> LT = getTLI()->getTypeLegalizationCost(Src);
|
|
|
|
|
|
|
|
// Assuming that all loads of legal types cost 1.
|
|
|
|
unsigned Cost = LT.first;
|
|
|
|
|
|
|
|
if (Src->isVectorTy() &&
|
|
|
|
Src->getPrimitiveSizeInBits() < LT.second.getSizeInBits()) {
|
|
|
|
// This is a vector load that legalizes to a larger type than the vector
|
|
|
|
// itself. Unless the corresponding extending load or truncating store is
|
|
|
|
// legal, then this will scalarize.
|
|
|
|
TargetLowering::LegalizeAction LA = TargetLowering::Expand;
|
|
|
|
EVT MemVT = getTLI()->getValueType(Src, true);
|
|
|
|
if (MemVT.isSimple() && MemVT != MVT::Other) {
|
|
|
|
if (Opcode == Instruction::Store)
|
|
|
|
LA = getTLI()->getTruncStoreAction(LT.second, MemVT.getSimpleVT());
|
|
|
|
else
|
|
|
|
LA = getTLI()->getLoadExtAction(ISD::EXTLOAD, LT.second, MemVT);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (LA != TargetLowering::Legal && LA != TargetLowering::Custom) {
|
|
|
|
// This is a vector load/store for some illegal type that is scalarized.
|
|
|
|
// We must account for the cost of building or decomposing the vector.
|
|
|
|
Cost += getScalarizationOverhead(Src, Opcode != Instruction::Store,
|
|
|
|
Opcode == Instruction::Store);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return Cost;
|
|
|
|
}
|
|
|
|
|
[LoopVectorize] Teach Loop Vectorizor about interleaved memory accesses.
Interleaved memory accesses are grouped and vectorized into vector load/store and shufflevector.
E.g. for (i = 0; i < N; i+=2) {
a = A[i]; // load of even element
b = A[i+1]; // load of odd element
... // operations on a, b, c, d
A[i] = c; // store of even element
A[i+1] = d; // store of odd element
}
The loads of even and odd elements are identified as an interleave load group, which will be transfered into vectorized IRs like:
%wide.vec = load <8 x i32>, <8 x i32>* %ptr
%vec.even = shufflevector <8 x i32> %wide.vec, <8 x i32> undef, <4 x i32> <i32 0, i32 2, i32 4, i32 6>
%vec.odd = shufflevector <8 x i32> %wide.vec, <8 x i32> undef, <4 x i32> <i32 1, i32 3, i32 5, i32 7>
The stores of even and odd elements are identified as an interleave store group, which will be transfered into vectorized IRs like:
%interleaved.vec = shufflevector <4 x i32> %vec.even, %vec.odd, <8 x i32> <i32 0, i32 4, i32 1, i32 5, i32 2, i32 6, i32 3, i32 7>
store <8 x i32> %interleaved.vec, <8 x i32>* %ptr
This optimization is currently disabled by defaut. To try it by adding '-enable-interleaved-mem-accesses=true'.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239291 91177308-0d34-0410-b5e6-96231b3b80d8
2015-06-08 06:39:56 +00:00
|
|
|
unsigned getInterleavedMemoryOpCost(unsigned Opcode, Type *VecTy,
|
|
|
|
unsigned Factor,
|
|
|
|
ArrayRef<unsigned> Indices,
|
|
|
|
unsigned Alignment,
|
|
|
|
unsigned AddressSpace) {
|
|
|
|
VectorType *VT = dyn_cast<VectorType>(VecTy);
|
|
|
|
assert(VT && "Expect a vector type for interleaved memory op");
|
|
|
|
|
|
|
|
unsigned NumElts = VT->getNumElements();
|
|
|
|
assert(Factor > 1 && NumElts % Factor == 0 && "Invalid interleave factor");
|
|
|
|
|
|
|
|
unsigned NumSubElts = NumElts / Factor;
|
|
|
|
VectorType *SubVT = VectorType::get(VT->getElementType(), NumSubElts);
|
|
|
|
|
|
|
|
// Firstly, the cost of load/store operation.
|
|
|
|
unsigned Cost = getMemoryOpCost(Opcode, VecTy, Alignment, AddressSpace);
|
|
|
|
|
|
|
|
// Then plus the cost of interleave operation.
|
|
|
|
if (Opcode == Instruction::Load) {
|
|
|
|
// The interleave cost is similar to extract sub vectors' elements
|
|
|
|
// from the wide vector, and insert them into sub vectors.
|
|
|
|
//
|
|
|
|
// E.g. An interleaved load of factor 2 (with one member of index 0):
|
|
|
|
// %vec = load <8 x i32>, <8 x i32>* %ptr
|
|
|
|
// %v0 = shuffle %vec, undef, <0, 2, 4, 6> ; Index 0
|
|
|
|
// The cost is estimated as extract elements at 0, 2, 4, 6 from the
|
|
|
|
// <8 x i32> vector and insert them into a <4 x i32> vector.
|
|
|
|
|
|
|
|
assert(Indices.size() <= Factor &&
|
|
|
|
"Interleaved memory op has too many members");
|
|
|
|
for (unsigned Index : Indices) {
|
|
|
|
assert(Index < Factor && "Invalid index for interleaved memory op");
|
|
|
|
|
|
|
|
// Extract elements from loaded vector for each sub vector.
|
|
|
|
for (unsigned i = 0; i < NumSubElts; i++)
|
|
|
|
Cost += getVectorInstrCost(Instruction::ExtractElement, VT,
|
|
|
|
Index + i * Factor);
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned InsSubCost = 0;
|
|
|
|
for (unsigned i = 0; i < NumSubElts; i++)
|
|
|
|
InsSubCost += getVectorInstrCost(Instruction::InsertElement, SubVT, i);
|
|
|
|
|
|
|
|
Cost += Indices.size() * InsSubCost;
|
|
|
|
} else {
|
|
|
|
// The interleave cost is extract all elements from sub vectors, and
|
|
|
|
// insert them into the wide vector.
|
|
|
|
//
|
|
|
|
// E.g. An interleaved store of factor 2:
|
|
|
|
// %v0_v1 = shuffle %v0, %v1, <0, 4, 1, 5, 2, 6, 3, 7>
|
|
|
|
// store <8 x i32> %interleaved.vec, <8 x i32>* %ptr
|
|
|
|
// The cost is estimated as extract all elements from both <4 x i32>
|
|
|
|
// vectors and insert into the <8 x i32> vector.
|
|
|
|
|
|
|
|
unsigned ExtSubCost = 0;
|
|
|
|
for (unsigned i = 0; i < NumSubElts; i++)
|
|
|
|
ExtSubCost += getVectorInstrCost(Instruction::ExtractElement, SubVT, i);
|
|
|
|
|
|
|
|
Cost += Factor * ExtSubCost;
|
|
|
|
|
|
|
|
for (unsigned i = 0; i < NumElts; i++)
|
|
|
|
Cost += getVectorInstrCost(Instruction::InsertElement, VT, i);
|
|
|
|
}
|
|
|
|
|
|
|
|
return Cost;
|
|
|
|
}
|
|
|
|
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
unsigned getIntrinsicInstrCost(Intrinsic::ID IID, Type *RetTy,
|
|
|
|
ArrayRef<Type *> Tys) {
|
|
|
|
unsigned ISD = 0;
|
|
|
|
switch (IID) {
|
|
|
|
default: {
|
|
|
|
// Assume that we need to scalarize this intrinsic.
|
|
|
|
unsigned ScalarizationCost = 0;
|
|
|
|
unsigned ScalarCalls = 1;
|
2015-03-17 19:37:28 +00:00
|
|
|
Type *ScalarRetTy = RetTy;
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
if (RetTy->isVectorTy()) {
|
|
|
|
ScalarizationCost = getScalarizationOverhead(RetTy, true, false);
|
|
|
|
ScalarCalls = std::max(ScalarCalls, RetTy->getVectorNumElements());
|
2015-03-17 19:37:28 +00:00
|
|
|
ScalarRetTy = RetTy->getScalarType();
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
}
|
2015-03-17 19:37:28 +00:00
|
|
|
SmallVector<Type *, 4> ScalarTys;
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
for (unsigned i = 0, ie = Tys.size(); i != ie; ++i) {
|
2015-03-17 19:37:28 +00:00
|
|
|
Type *Ty = Tys[i];
|
|
|
|
if (Ty->isVectorTy()) {
|
|
|
|
ScalarizationCost += getScalarizationOverhead(Ty, false, true);
|
|
|
|
ScalarCalls = std::max(ScalarCalls, Ty->getVectorNumElements());
|
|
|
|
Ty = Ty->getScalarType();
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
}
|
2015-03-17 19:37:28 +00:00
|
|
|
ScalarTys.push_back(Ty);
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
}
|
2015-03-17 19:37:28 +00:00
|
|
|
if (ScalarCalls == 1)
|
|
|
|
return 1; // Return cost of a scalar intrinsic. Assume it to be cheap.
|
|
|
|
|
|
|
|
unsigned ScalarCost = static_cast<T *>(this)->getIntrinsicInstrCost(
|
|
|
|
IID, ScalarRetTy, ScalarTys);
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
|
2015-03-17 19:37:28 +00:00
|
|
|
return ScalarCalls * ScalarCost + ScalarizationCost;
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
}
|
|
|
|
// Look for intrinsics that can be lowered directly or turned into a scalar
|
|
|
|
// intrinsic call.
|
|
|
|
case Intrinsic::sqrt:
|
|
|
|
ISD = ISD::FSQRT;
|
|
|
|
break;
|
|
|
|
case Intrinsic::sin:
|
|
|
|
ISD = ISD::FSIN;
|
|
|
|
break;
|
|
|
|
case Intrinsic::cos:
|
|
|
|
ISD = ISD::FCOS;
|
|
|
|
break;
|
|
|
|
case Intrinsic::exp:
|
|
|
|
ISD = ISD::FEXP;
|
|
|
|
break;
|
|
|
|
case Intrinsic::exp2:
|
|
|
|
ISD = ISD::FEXP2;
|
|
|
|
break;
|
|
|
|
case Intrinsic::log:
|
|
|
|
ISD = ISD::FLOG;
|
|
|
|
break;
|
|
|
|
case Intrinsic::log10:
|
|
|
|
ISD = ISD::FLOG10;
|
|
|
|
break;
|
|
|
|
case Intrinsic::log2:
|
|
|
|
ISD = ISD::FLOG2;
|
|
|
|
break;
|
|
|
|
case Intrinsic::fabs:
|
|
|
|
ISD = ISD::FABS;
|
|
|
|
break;
|
|
|
|
case Intrinsic::minnum:
|
|
|
|
ISD = ISD::FMINNUM;
|
|
|
|
break;
|
|
|
|
case Intrinsic::maxnum:
|
|
|
|
ISD = ISD::FMAXNUM;
|
|
|
|
break;
|
|
|
|
case Intrinsic::copysign:
|
|
|
|
ISD = ISD::FCOPYSIGN;
|
|
|
|
break;
|
|
|
|
case Intrinsic::floor:
|
|
|
|
ISD = ISD::FFLOOR;
|
|
|
|
break;
|
|
|
|
case Intrinsic::ceil:
|
|
|
|
ISD = ISD::FCEIL;
|
|
|
|
break;
|
|
|
|
case Intrinsic::trunc:
|
|
|
|
ISD = ISD::FTRUNC;
|
|
|
|
break;
|
|
|
|
case Intrinsic::nearbyint:
|
|
|
|
ISD = ISD::FNEARBYINT;
|
|
|
|
break;
|
|
|
|
case Intrinsic::rint:
|
|
|
|
ISD = ISD::FRINT;
|
|
|
|
break;
|
|
|
|
case Intrinsic::round:
|
|
|
|
ISD = ISD::FROUND;
|
|
|
|
break;
|
|
|
|
case Intrinsic::pow:
|
|
|
|
ISD = ISD::FPOW;
|
|
|
|
break;
|
|
|
|
case Intrinsic::fma:
|
|
|
|
ISD = ISD::FMA;
|
|
|
|
break;
|
|
|
|
case Intrinsic::fmuladd:
|
|
|
|
ISD = ISD::FMA;
|
|
|
|
break;
|
|
|
|
// FIXME: We should return 0 whenever getIntrinsicCost == TCC_Free.
|
|
|
|
case Intrinsic::lifetime_start:
|
|
|
|
case Intrinsic::lifetime_end:
|
|
|
|
return 0;
|
|
|
|
case Intrinsic::masked_store:
|
|
|
|
return static_cast<T *>(this)
|
|
|
|
->getMaskedMemoryOpCost(Instruction::Store, Tys[0], 0, 0);
|
|
|
|
case Intrinsic::masked_load:
|
|
|
|
return static_cast<T *>(this)
|
|
|
|
->getMaskedMemoryOpCost(Instruction::Load, RetTy, 0, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
const TargetLoweringBase *TLI = getTLI();
|
|
|
|
std::pair<unsigned, MVT> LT = TLI->getTypeLegalizationCost(RetTy);
|
|
|
|
|
|
|
|
if (TLI->isOperationLegalOrPromote(ISD, LT.second)) {
|
|
|
|
// The operation is legal. Assume it costs 1.
|
|
|
|
// If the type is split to multiple registers, assume that there is some
|
|
|
|
// overhead to this.
|
|
|
|
// TODO: Once we have extract/insert subvector cost we need to use them.
|
|
|
|
if (LT.first > 1)
|
|
|
|
return LT.first * 2;
|
|
|
|
return LT.first * 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!TLI->isOperationExpand(ISD, LT.second)) {
|
|
|
|
// If the operation is custom lowered then assume
|
|
|
|
// thare the code is twice as expensive.
|
|
|
|
return LT.first * 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If we can't lower fmuladd into an FMA estimate the cost as a floating
|
|
|
|
// point mul followed by an add.
|
|
|
|
if (IID == Intrinsic::fmuladd)
|
|
|
|
return static_cast<T *>(this)
|
|
|
|
->getArithmeticInstrCost(BinaryOperator::FMul, RetTy) +
|
|
|
|
static_cast<T *>(this)
|
|
|
|
->getArithmeticInstrCost(BinaryOperator::FAdd, RetTy);
|
|
|
|
|
|
|
|
// Else, assume that we need to scalarize this intrinsic. For math builtins
|
|
|
|
// this will emit a costly libcall, adding call overhead and spills. Make it
|
|
|
|
// very expensive.
|
|
|
|
if (RetTy->isVectorTy()) {
|
2015-03-17 19:37:28 +00:00
|
|
|
unsigned ScalarizationCost = getScalarizationOverhead(RetTy, true, false);
|
|
|
|
unsigned ScalarCalls = RetTy->getVectorNumElements();
|
|
|
|
SmallVector<Type *, 4> ScalarTys;
|
|
|
|
for (unsigned i = 0, ie = Tys.size(); i != ie; ++i) {
|
|
|
|
Type *Ty = Tys[i];
|
|
|
|
if (Ty->isVectorTy())
|
|
|
|
Ty = Ty->getScalarType();
|
|
|
|
ScalarTys.push_back(Ty);
|
|
|
|
}
|
|
|
|
unsigned ScalarCost = static_cast<T *>(this)->getIntrinsicInstrCost(
|
|
|
|
IID, RetTy->getScalarType(), ScalarTys);
|
|
|
|
for (unsigned i = 0, ie = Tys.size(); i != ie; ++i) {
|
|
|
|
if (Tys[i]->isVectorTy()) {
|
|
|
|
ScalarizationCost += getScalarizationOverhead(Tys[i], false, true);
|
|
|
|
ScalarCalls = std::max(ScalarCalls, Tys[i]->getVectorNumElements());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return ScalarCalls * ScalarCost + ScalarizationCost;
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// This is going to be turned into a library call, make it expensive.
|
|
|
|
return 10;
|
|
|
|
}
|
|
|
|
|
2015-03-17 19:26:23 +00:00
|
|
|
/// \brief Compute a cost of the given call instruction.
|
|
|
|
///
|
|
|
|
/// Compute the cost of calling function F with return type RetTy and
|
|
|
|
/// argument types Tys. F might be nullptr, in this case the cost of an
|
|
|
|
/// arbitrary call with the specified signature will be returned.
|
|
|
|
/// This is used, for instance, when we estimate call of a vector
|
|
|
|
/// counterpart of the given function.
|
|
|
|
/// \param F Called function, might be nullptr.
|
2015-03-18 02:09:25 +00:00
|
|
|
/// \param RetTy Return value types.
|
|
|
|
/// \param Tys Argument types.
|
2015-03-17 19:26:23 +00:00
|
|
|
/// \returns The cost of Call instruction.
|
|
|
|
unsigned getCallInstrCost(Function *F, Type *RetTy, ArrayRef<Type *> Tys) {
|
|
|
|
return 10;
|
|
|
|
}
|
|
|
|
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
unsigned getNumberOfParts(Type *Tp) {
|
|
|
|
std::pair<unsigned, MVT> LT = getTLI()->getTypeLegalizationCost(Tp);
|
|
|
|
return LT.first;
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned getAddressComputationCost(Type *Ty, bool IsComplex) { return 0; }
|
|
|
|
|
|
|
|
unsigned getReductionCost(unsigned Opcode, Type *Ty, bool IsPairwise) {
|
|
|
|
assert(Ty->isVectorTy() && "Expect a vector type");
|
|
|
|
unsigned NumVecElts = Ty->getVectorNumElements();
|
|
|
|
unsigned NumReduxLevels = Log2_32(NumVecElts);
|
|
|
|
unsigned ArithCost =
|
|
|
|
NumReduxLevels *
|
|
|
|
static_cast<T *>(this)->getArithmeticInstrCost(Opcode, Ty);
|
|
|
|
// Assume the pairwise shuffles add a cost.
|
|
|
|
unsigned ShuffleCost =
|
|
|
|
NumReduxLevels * (IsPairwise + 1) *
|
|
|
|
static_cast<T *>(this)
|
|
|
|
->getShuffleCost(TTI::SK_ExtractSubvector, Ty, NumVecElts / 2, Ty);
|
|
|
|
return ShuffleCost + ArithCost + getScalarizationOverhead(Ty, false, true);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// @}
|
|
|
|
};
|
2015-01-31 11:17:59 +00:00
|
|
|
|
|
|
|
/// \brief Concrete BasicTTIImpl that can be used if no further customization
|
|
|
|
/// is needed.
|
|
|
|
class BasicTTIImpl : public BasicTTIImplBase<BasicTTIImpl> {
|
|
|
|
typedef BasicTTIImplBase<BasicTTIImpl> BaseT;
|
2015-02-01 14:01:15 +00:00
|
|
|
friend class BasicTTIImplBase<BasicTTIImpl>;
|
|
|
|
|
2015-02-01 14:22:17 +00:00
|
|
|
const TargetSubtargetInfo *ST;
|
2015-02-01 14:01:15 +00:00
|
|
|
const TargetLoweringBase *TLI;
|
|
|
|
|
2015-02-01 14:22:17 +00:00
|
|
|
const TargetSubtargetInfo *getST() const { return ST; }
|
2015-02-01 14:01:15 +00:00
|
|
|
const TargetLoweringBase *getTLI() const { return TLI; }
|
2015-01-31 11:17:59 +00:00
|
|
|
|
|
|
|
public:
|
2015-02-01 14:22:17 +00:00
|
|
|
explicit BasicTTIImpl(const TargetMachine *ST, Function &F);
|
2015-01-31 11:17:59 +00:00
|
|
|
|
|
|
|
// Provide value semantics. MSVC requires that we spell all of these out.
|
|
|
|
BasicTTIImpl(const BasicTTIImpl &Arg)
|
2015-02-01 14:22:17 +00:00
|
|
|
: BaseT(static_cast<const BaseT &>(Arg)), ST(Arg.ST), TLI(Arg.TLI) {}
|
2015-01-31 11:17:59 +00:00
|
|
|
BasicTTIImpl(BasicTTIImpl &&Arg)
|
2015-02-01 14:22:17 +00:00
|
|
|
: BaseT(std::move(static_cast<BaseT &>(Arg))), ST(std::move(Arg.ST)),
|
2015-02-01 14:01:15 +00:00
|
|
|
TLI(std::move(Arg.TLI)) {}
|
2015-01-31 11:17:59 +00:00
|
|
|
BasicTTIImpl &operator=(const BasicTTIImpl &RHS) {
|
|
|
|
BaseT::operator=(static_cast<const BaseT &>(RHS));
|
2015-02-01 14:22:17 +00:00
|
|
|
ST = RHS.ST;
|
2015-02-01 14:01:15 +00:00
|
|
|
TLI = RHS.TLI;
|
2015-01-31 11:17:59 +00:00
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
BasicTTIImpl &operator=(BasicTTIImpl &&RHS) {
|
|
|
|
BaseT::operator=(std::move(static_cast<BaseT &>(RHS)));
|
2015-02-01 14:22:17 +00:00
|
|
|
ST = std::move(RHS.ST);
|
2015-02-01 14:01:15 +00:00
|
|
|
TLI = std::move(RHS.TLI);
|
2015-01-31 11:17:59 +00:00
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2015-06-23 09:49:53 +00:00
|
|
|
}
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
|
|
|
|
#endif
|