(on solaris10, which are:
CodeGen/PowerPC/frounds.ll
Transforms/InstCombine/2008-02-23-MulSub.ll)
I needed a tool to figure out which one is the guilty.
To this end I have added a verbosity
option to the test/Makefile.
It can be invoked thus:
gmake check TESTSUITE=CodeGen/PowerPC VERBOSE="-v -v"
(The number of "-v"s specifies the verbosity level.
Instead of "-v" other aliases can be specified,
please consult the dejagnu docs for info.)
At level >= 2 following line is logged for each
test, before running it:
ABOUT TO RUN: <test>.ll
llvm-svn: 47602
CodeGen/PowerPC/illegal-element-type.ll): suppose
a node X is processed, and processing maps it to
a node Y. Then X continues to exist in the DAG,
but with no users. While processing some other
node, a new node may be created that happens to
be equal to X, and thus X will be reused rather
than a truly new node. This can cause X to
"magically reappear", and since it is in the
Processed state in will not be reprocessed, so
at the end of type legalization the illegal node
X can still be present. The solution is to replace
X with Y whenever X gets resurrected like this.
llvm-svn: 47601
GOT-style position independent code. Before only tail calls to
protected/hidden functions within the same module were optimized.
Now all function calls are tail call optimized.
llvm-svn: 47594
calls. Before arguments that could overwrite each other were
explicitly lowered to a stack slot, not giving the register allocator
a chance to optimize. Now a sequence of copyto/copyfrom virtual
registers ensures that arguments are loaded in (virtual) registers
before they are lowered to the stack slot (and might overwrite each
other). Also parameter stack slots are marked mutable for
(potentially) tail calling functions.
llvm-svn: 47593
after legalize. Just because a constant is legal (e.g. 0.0 in SSE)
doesn't mean that its negated value is legal (-0.0). We could make
this stronger by checking to see if the negated constant is actually
legal post negation, but it doesn't seem like a big deal.
llvm-svn: 47591
result into a MUL late in the X86 codegen process. ISD::MUL is
once again Legal on X86, so this is no longer needed. And, the
hack was suboptimal; see PR1874 for details.
llvm-svn: 47567
