directly from the intrinsics produced by the frontend. If it is more
convenient to have a custom DAG node for using these to implement shuffles,
we can add that later.
llvm-svn: 78459
so that terminal states are as simple as possible.
- If we were willing to assume that the order that operands get inserted in the
MCInst is fixed we could actually dispose with this altogether, although it
might be nice to have the flexibility to change it later.
llvm-svn: 78458
as vector shuffles did not work out well. Shuffles that produce double-wide
vectors accurately represent the operation but make it hard to do anything
with the results. I considered splitting them up into 2 shuffles, one to
write each register separately, but there doesn't seem to be a good way to
reunite them for codegen.
llvm-svn: 78437
driven by TAI to being static, driven by tblgen. This means that a
target doesn't get impacted by this stuff at all if it doesn't opt
into it.
llvm-svn: 78427
The use case is if you have a wrapper class:
class Base {
void *Ptr;
public:
Base() : Ptr(0) { }
operator bool() const { return Ptr; }
.....
}
and sub-wrappers that have exactly the same size:
class Sub : public Base {
public:
....
static bool classof(const Base*);
}
and in the code you would do:
void f(Base b) {
Sub sub = dyn_cast<Sub>(b);
if (sub) {
....
}
}
llvm-svn: 78424
I can clean this up a bit more and do way with the TheCondState and just use
the top element on the TheCondStack if not empty. Also may tweak the code
around ParseConditionalAssemblyDirectives() to simplify the AsmParser code.
llvm-svn: 78423
http://llvm.org/viewvc/llvm-project?view=rev&revision=78127, I'm changing the
ExecutionEngine's global mappings to hold AssertingVH<const GlobalValue>. That
way, if unregistering a mapping fails to actually unregister it, we'll get an
assert. Running the jit nightly tests didn't uncover any actual instances of
the problem.
This also uncovered the fact that AssertingVH<const X> didn't work, so I fixed
that too.
llvm-svn: 78400
LoopDependenceAnalysis::getLoops is currently O(N*M) for a loop-nest of
depth N and a compound SCEV of M atomic SCEVs. As both N and M will
typically be very small, this should not be a problem. If it turns out
to be one, rewriting getLoops as SCEVVisitor will reduce complexity to
O(M).
llvm-svn: 78394
