The order in which operands appear in the encoded instruction is different
to order in which they appear in assembly. This changes the XCore backend to
use the instruction encoding order.
llvm-svn: 173493
politely report it instead of running into llvm_unreachable.
Also patch llvm-dwarfdump to actually check whether the file it's attempting to
dump is a valid object file.
llvm-svn: 173489
This warning fires on:
Operator::~Operator() {
llvm_unreachable("should never destroy an Operator");
}
That seems like a false positive. I don't see any good way to silence
the warning here, so I'm disabling it.
llvm-svn: 173455
Only for integers, pointers, and vectors of those. No floats.
Instrumentation seems very heavy, and may need to be replaced
with some approximation in the future.
llvm-svn: 173452
with an initial number of elements, instead of DenseMap, which has
zero initial elements, in order to avoid the copying of elements
when the size changes and to avoid allocating space every time
LegalizeTypes is run. This patch will not affect the memory footprint,
because DenseMap will increase the element size to 64
when the first element is added.
Patch by Wan Xiaofei.
llvm-svn: 173448
Maintain separate per-node and per-tree book-keeping.
Track all instructions above a DAG node including nested subtrees.
Seperately track instructions within a subtree.
Record subtree parents.
llvm-svn: 173426
loops over instructions in the basic block or the use-def list of the
value, neither of which are really efficient when repeatedly querying
about values in the same basic block.
What's more, we already know that the CondBB is small, and so we can do
a much more efficient test by counting the uses in CondBB, and seeing if
those account for all of the uses.
Finally, we shouldn't blanket fail on any such instruction, instead we
should conservatively assume that those instructions are part of the
cost.
Note that this actually fixes a bug in the pass because
isUsedInBasicBlock has a really terrible bug in it. I'll fix that in my
next commit, but the fix for it would make this code suddenly take the
compile time hit I thought it already was taking, so I wanted to go
ahead and migrate this code to a faster & better pattern.
The bug in isUsedInBasicBlock was also causing other tests to test the
wrong thing entirely: for example we weren't actually disabling
speculation for floating point operations as intended (and tested), but
the test passed because we failed to speculate them due to the
isUsedInBasicBlock failure.
llvm-svn: 173417
For sanity, create a root when NumDataSuccs >= 4. Splitting large
subtrees will no longer be detrimental after my next checkin to handle
nested tree. A magic number of 4 is fine because single subtrees
seldom rejoin more than this. It makes subtrees easier to visualize
and heuristics more sane.
llvm-svn: 173399
No functionality change intended.
This captures the first two cases GPR32/64. For the others, we need
an addition operator (if we have one, I've not yet found it).
Based on a suggestion made by Tom Stellard in the AArch64 review!
llvm-svn: 173366
Change messages to help identify which interpreter was actually selected (safe
vs testing).
Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
Reviewed-by: Chandler Carruth <chandlerc@gmail.com>
llvm-svn: 173360
Jakub Staszak