so that va_start/va_arg/et.al. will walk arguments correctly for Cell SPU.
N.B.: Because neither clang nor llvm-gcc-4.2 can be built for CellSPU, this is
still unexorcised code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58415 91177308-0d34-0410-b5e6-96231b3b80d8
allows ppcf128->int conversion to work with
DeadInstructionElimination. This is now turned
off but RM is harmless. It does not do a complete
job of modeling the rounding mode.
Revert marking MFCR as using all 7 CR subregisters;
while correct, this caused the problem in PR 2964,
plus the local RA crash noted in the comments.
This was needed to make DeadInstructionElimination,
but as we are not running that, it is backed out
for now. Eventually it should go back in and the
other problems fixed where they're broken.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58391 91177308-0d34-0410-b5e6-96231b3b80d8
other day that PPC custom lowering could create
a BUILD_PAIR of two f64 with a result type of...
f64! - already fixed). Fix a place that triggers
the sanity check.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58378 91177308-0d34-0410-b5e6-96231b3b80d8
is morphed by AnalyzeNewNode into a previously
processed node, and different result values of
that node are remapped to values with different
nodes, then we could end up using wrong values
here [we were assuming that all results remap
to values with the same underlying node]. This
seems theoretically possible, but I don't have
a testcase. The meat of the patch is in the
changes to AnalyzeNewNode/AnalyzeNewValue and
ReplaceNodeWith. While there, I changed names
like RemapNode to RemapValue, since it really
remaps values. To tell the truth, I would be
much happier if we were only remapping nodes
(it would simplify a bunch of logic, and allow
for some cute speedups) but I haven't yet worked
out how to do that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58372 91177308-0d34-0410-b5e6-96231b3b80d8
- One functionality change, '\\' in a name is now printed as a hex
escape instead of "\\\\". This is consistent with other users of
PrintEscapedString.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58343 91177308-0d34-0410-b5e6-96231b3b80d8
Since the ARM constant pool handling supercedes the standard LLVM constant
pool entirely, the JIT emitter does not allocate space for the constants,
nor initialize the memory. The constant pool is considered part of the
instruction stream.
Likewise, when resolving relocations into the constant pool, a hook into
the target back end is used to resolve from the constant ID# to the
address where the constant is stored.
For now, the support in the ARM emitter is limited to 32-bit integer. Future
patches will expand this to the full range of constants necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58338 91177308-0d34-0410-b5e6-96231b3b80d8
ppcf128 to i32 conversion and expand it into a code
sequence like in LegalizeDAG. This needs custom
ppc lowering of FP_ROUND_INREG, so turn that on and
make it work with LegalizeTypes. Probably PPC should
simply custom lower the original conversion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58329 91177308-0d34-0410-b5e6-96231b3b80d8
id could end up being wrong mostly because of
forgetting to remap new nodes that morphed into
processed nodes through CSE.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58323 91177308-0d34-0410-b5e6-96231b3b80d8
a memset using 16-byte XMM stores, but where the stack realignment code
didn't work. Until it does (PR2962) disable use of xmm regs in memcpy
and memset formation for linux and other targets with insufficiently
aligned stacks.
This is part of PR2888
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58317 91177308-0d34-0410-b5e6-96231b3b80d8
flag. Then in a debugger developers can set breakpoints at these calls
to see waht is about to be selected and what the resulting subgraph
looks like. This really helps when debugging instruction selection.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58278 91177308-0d34-0410-b5e6-96231b3b80d8
can give it the same stack slot as the spilled interval if it is folded.
This prevents the fold/unfold code from pointing to the wrong register.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58255 91177308-0d34-0410-b5e6-96231b3b80d8
(and a bunch of other node types). While there, I
added a doNotCSE predicate and used it to reduce code
duplication (some of the duplicated code was wrong...).
This fixes ARM/cse-libcalls.ll when using LegalizeTypes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58249 91177308-0d34-0410-b5e6-96231b3b80d8
worklist twice: UpdateNodeOperands could morph
a new node into a node already on the worklist.
We would then recalculate the NodeId for this
existing node and add it to the worklist. The
testcase is ARM/cse-libcalls.ll, the problem
showing up once UpdateNodeOperands is taught to
do CSE for calls.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58246 91177308-0d34-0410-b5e6-96231b3b80d8
LargeBlockInfo, we can now dramatically simplify their implementation
and speed them up at the same time. Now the code has time proportional
to the number of uses of the alloca, not the size of the block.
This also eliminates code that tried to batch up different allocas which
are used in the same blocks, and eliminates the 'retry list' logic which
was baroque and no unneccesary. In addition to being a speedup for crazy
cases, this is also a nice cleanup:
PromoteMemoryToRegister.cpp | 270 +++++++++++++++-----------------------------
1 file changed, 96 insertions(+), 174 deletions(-)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58229 91177308-0d34-0410-b5e6-96231b3b80d8
a trivial dense map. Use this in RewriteSingleStoreAlloca to
avoid aggressively rescanning blocks over and over again. This
fixes PR2925, speeding up mem2reg on the testcase in that bug
from 4.56s to 0.02s in a debug build on my machine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58227 91177308-0d34-0410-b5e6-96231b3b80d8
