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
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
result type when the result type is legal but
not the operand type. Add additional support
for EXTRACT_SUBVECTOR and CONCAT_VECTORS,
needed to handle such cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@57840 91177308-0d34-0410-b5e6-96231b3b80d8
The first can update the SDNode in an SDValue
while the second is called with SDNode* and
returns a possibly updated SDNode*.
This patch has no intended functional impact,
but helps eliminating ugly temporary SDValues.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55608 91177308-0d34-0410-b5e6-96231b3b80d8
FPROUND_F80_F32, FPROUND_PPCF128_F32,
FPROUND_F80_F64, FPROUND_PPCF128_F64
Support for soften float fp_round operands is added, Mips
needs this to round f64->f32.
Also added support to soften float FABS result, Mips doesn't
support double fabs results while in 'single float only' mode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54484 91177308-0d34-0410-b5e6-96231b3b80d8
In LegalizeDAG the value is zero-extended to
the new type before byte swapping. It doesn't
matter how the extension is done since the new
bits are shifted off anyway after the swap, so
extend by any old rubbish bits. This results
in the final assembler for the testcase being
one line shorter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53604 91177308-0d34-0410-b5e6-96231b3b80d8
are used for passing huge immediates in inline ASM
from the front-end straight down to the ASM writer.
Of course this is a hack, but it is simple, limited
in scope, works in practice, and is what LegalizeDAG
does.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53553 91177308-0d34-0410-b5e6-96231b3b80d8
SINT_TO_FP libcall plus additional operations:
it might as well be a direct UINT_TO_FP libcall.
So only turn it into an SINT_TO_FP if the target
has special handling for SINT_TO_FP.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53461 91177308-0d34-0410-b5e6-96231b3b80d8
SINT_TO_FP and UINT_TO_FP. This now produces
the same code as LegalizeDAG (the previous
code was based on a mistaken idea of what
LegalizeDAG did in this case).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53288 91177308-0d34-0410-b5e6-96231b3b80d8
soft float: experiments show that targets aren't
expecting this for results or for operands. Add
support select/select_cc result soft float and
correct operand soft float for these.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53245 91177308-0d34-0410-b5e6-96231b3b80d8
For this it is convenient to permit floats to
be used with EXTRACT_ELEMENT, so I tweaked
things to allow that. I also added libcalls
for ppcf128 to i32 forms of FP_TO_XINT, since
they exist in libgcc and this case can certainly
occur (and does occur in the testsuite) - before
the i64 libcall was being used. Also, the
XINT_TO_FP result seemed to be wrong when
the argument is an i128: the wrong fudge
factor was added (the i32 and i64 cases were
handled directly, but the i128 code fell
through to some generic softening code which
seemed to think it was i64 to f32!). So I
fixed it by adding a fudge factor that I
found in my breakfast cereal.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52739 91177308-0d34-0410-b5e6-96231b3b80d8
integer of the same type. Before it was "promotion",
but this is confusing because it is quite different
to promotion of integers. Call it "softening" instead,
inspired by "soft float".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52546 91177308-0d34-0410-b5e6-96231b3b80d8
rather than bundling them together. Rename FloatToInt
to PromoteFloat (better, if not perfect). Reorganize
files by types rather than by operations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52408 91177308-0d34-0410-b5e6-96231b3b80d8
maps can be deleted. This happens when RAUW
replaces a node N with another equivalent node
E, deleting the first node. Solve this by
adding (N, E) to ReplacedNodes, which is already
used to remap nodes to replacements. This means
that deleted nodes are being allowed in maps,
which can be delicate: the memory may be reused
for a new node which might get confused with the
old deleted node pointer hanging around in the
maps, so detect this and flush out maps if it
occurs (ExpungeNode). The expunging operation
is expensive, however it never occurs during
a llvm-gcc bootstrap or anywhere in the nightly
testsuite. It occurs three times in "make check":
Alpha/illegal-element-type.ll,
PowerPC/illegal-element-type.ll and
X86/mmx-shift.ll. If expunging proves to be too
expensive then there are other more complicated
ways of solving the problem.
In the normal case this patch adds the overhead
of a few more map lookups, which is hopefully
negligable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52214 91177308-0d34-0410-b5e6-96231b3b80d8
