to be shared, but how/where to privatize it is not immediately clear to me.
If any SelectionDAG experts see a better solution, please share!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74180 91177308-0d34-0410-b5e6-96231b3b80d8
Update code generator to use this attribute and remove NoImplicitFloat target option.
Update llc to set this attribute when -no-implicit-float command line option is used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72959 91177308-0d34-0410-b5e6-96231b3b80d8
instcombine doesn't know when it's safe. To partially compensate
for this, introduce new code to do this transformation in
dagcombine, which can use UnsafeFPMath.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72872 91177308-0d34-0410-b5e6-96231b3b80d8
ADDC/ADDE use MVT::i1 (later, whatever it gets legalized to)
instead of MVT::Flag. Remove CARRY_FALSE in favor of 0; adjust
all target-independent code to use this format.
Most targets will still produce a Flag-setting target-dependent
version when selection is done. X86 is converted to use i32
instead, which means TableGen needs to produce different code
in xxxGenDAGISel.inc. This keys off the new supportsHasI1 bit
in xxxInstrInfo, currently set only for X86; in principle this
is temporary and should go away when all other targets have
been converted. All relevant X86 instruction patterns are
modified to represent setting and using EFLAGS explicitly. The
same can be done on other targets.
The immediate behavior change is that an ADC/ADD pair are no
longer tightly coupled in the X86 scheduler; they can be
separated by instructions that don't clobber the flags (MOV).
I will soon add some peephole optimizations based on using
other instructions that set the flags to feed into ADC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72707 91177308-0d34-0410-b5e6-96231b3b80d8
shows up in -print-machineinstrs. This doesn't appear to affect anything, but it was
weird for some DBG_LABELs to have DebugLocs but not all of them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70921 91177308-0d34-0410-b5e6-96231b3b80d8
PR2957
ISD::VECTOR_SHUFFLE now stores an array of integers representing the shuffle
mask internal to the node, rather than taking a BUILD_VECTOR of ConstantSDNodes
as the shuffle mask. A value of -1 represents UNDEF.
In addition to eliminating the creation of illegal BUILD_VECTORS just to
represent shuffle masks, we are better about canonicalizing the shuffle mask,
resulting in substantially better code for some classes of shuffles.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70225 91177308-0d34-0410-b5e6-96231b3b80d8
This particular one is undefined behavior (although this
isn't related to the crash), so it will no longer do it
at compile time, which seems better.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69990 91177308-0d34-0410-b5e6-96231b3b80d8
ISD::VECTOR_SHUFFLE now stores an array of integers representing the shuffle
mask internal to the node, rather than taking a BUILD_VECTOR of ConstantSDNodes
as the shuffle mask. A value of -1 represents UNDEF.
In addition to eliminating the creation of illegal BUILD_VECTORS just to
represent shuffle masks, we are better about canonicalizing the shuffle mask,
resulting in substantially better code for some classes of shuffles.
A clean up of x86 shuffle code, and some canonicalizing in DAGCombiner is next.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69952 91177308-0d34-0410-b5e6-96231b3b80d8
bigger than the vector element type, turn checking
of the operand type back on again, appropriately
adjusted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69516 91177308-0d34-0410-b5e6-96231b3b80d8
type as the vector element type: allow them to be of
a wider integer type than the element type all the way
through the system, and not just as far as LegalizeDAG.
This should be safe because it used to be this way
(the old type legalizer would produce such nodes), so
backends should be able to handle it. In fact only
targets which have legal vector types with an illegal
promoted element type will ever see this (eg: <4 x i16>
on ppc). This fixes a regression with the new type
legalizer (vec_splat.ll). Also, treat SCALAR_TO_VECTOR
the same as BUILD_VECTOR. After all, it is just a
special case of BUILD_VECTOR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69467 91177308-0d34-0410-b5e6-96231b3b80d8
to support replacing a node with another that has a superset of
the result types. Use this instead of calling
ReplaceAllUsesOfValueWith for each value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69209 91177308-0d34-0410-b5e6-96231b3b80d8
promoted to legal types without changing the type of the vector. This is
following a suggestion from Duncan
(http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-February/019923.html).
The transformation that used to be done during type legalization is now
postponed to DAG legalization. This allows the BUILD_VECTORs to be optimized
and potentially handled specially by target-specific code.
It turns out that this is also consistent with an optimization done by the
DAG combiner: a BUILD_VECTOR and INSERT_VECTOR_ELT may be combined by
replacing one of the BUILD_VECTOR operands with the newly inserted element;
but INSERT_VECTOR_ELT allows its scalar operand to be larger than the
element type, with any extra high bits being implicitly truncated. The
result is a BUILD_VECTOR where one of the operands has a type larger the
the vector element type.
Any code that operates on BUILD_VECTORs may now need to be aware of the
potential type discrepancy between the vector element type and the
BUILD_VECTOR operands. This patch updates all of the places that I could
find to handle that case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@68996 91177308-0d34-0410-b5e6-96231b3b80d8
Note that these are distinct from TargetInstrInfo::INSERT_SUBREG
and TargetInstrInfo::EXTRACT_SUBREG, which are used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@68355 91177308-0d34-0410-b5e6-96231b3b80d8
1. ConstantPoolSDNode alignment field is log2 value of the alignment requirement. This is not consistent with other SDNode variants.
2. MachineConstantPool alignment field is also a log2 value.
3. However, some places are creating ConstantPoolSDNode with alignment value rather than log2 values. This creates entries with artificially large alignments, e.g. 256 for SSE vector values.
4. Constant pool entry offsets are computed when they are created. However, asm printer group them by sections. That means the offsets are no longer valid. However, asm printer uses them to determine size of padding between entries.
5. Asm printer uses expensive data structure multimap to track constant pool entries by sections.
6. Asm printer iterate over SmallPtrSet when it's emitting constant pool entries. This is non-deterministic.
Solutions:
1. ConstantPoolSDNode alignment field is changed to keep non-log2 value.
2. MachineConstantPool alignment field is also changed to keep non-log2 value.
3. Functions that create ConstantPool nodes are passing in non-log2 alignments.
4. MachineConstantPoolEntry no longer keeps an offset field. It's replaced with an alignment field. Offsets are not computed when constant pool entries are created. They are computed on the fly in asm printer and JIT.
5. Asm printer uses cheaper data structure to group constant pool entries.
6. Asm printer compute entry offsets after grouping is done.
7. Change JIT code to compute entry offsets on the fly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@66875 91177308-0d34-0410-b5e6-96231b3b80d8
It is an error to call APInt::zext with a size that is equal to the value's
current size, so use zextOrTrunc instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@66039 91177308-0d34-0410-b5e6-96231b3b80d8
arbitrary vector sizes. Add an optional MinSplatBits parameter to specify
a minimum for the splat element size. Update the PPC target to use the
revised interface.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@65899 91177308-0d34-0410-b5e6-96231b3b80d8
results via reference parameters.
This patch also appears to fix Evan's reported problem supplied as a
reduced bugpoint test case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@65426 91177308-0d34-0410-b5e6-96231b3b80d8
ashr instcombine to help expose this code. And apply the fix to
SelectionDAG's copy of this code too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@65364 91177308-0d34-0410-b5e6-96231b3b80d8
instruction. The class also consolidates the code for detecting constant
splats that's shared across PowerPC and the CellSPU backends (and might be
useful for other backends.) Also introduces SelectionDAG::getBUID_VECTOR() for
generating new BUILD_VECTOR nodes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@65296 91177308-0d34-0410-b5e6-96231b3b80d8
(Note: Eventually, commits like this will be handled via a pre-commit hook that
does this automagically, as well as expand tabs to spaces and look for 80-col
violations.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@64827 91177308-0d34-0410-b5e6-96231b3b80d8
Adjust derived classes to pass UnknownLoc where
a DebugLoc does not make sense. Pick one of
DebugLoc and non-DebugLoc variants to survive
for all such classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@64000 91177308-0d34-0410-b5e6-96231b3b80d8
Many targets build placeholder nodes for special operands, e.g.
GlobalBaseReg on X86 and PPC for the PIC base. There's no
sensible way to associate debug info with these. I've left
them built with getNode calls with explicit DebugLoc::getUnknownLoc operands.
I'm not too happy about this but don't see a good improvement;
I considered adding a getPseudoOperand or something, but it
seems to me that'll just make it harder to read.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@63992 91177308-0d34-0410-b5e6-96231b3b80d8
getCALLSEQ_{END,START} to permit passing no DebugLoc
there. UNDEF doesn't logically have DebugLoc; add
getUNDEF to encapsulate this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@63978 91177308-0d34-0410-b5e6-96231b3b80d8
support GraphViz, I've been using the foo->dump() facility. This
patch is a minor rewrite to the SelectionDAG dump() stuff to make it a
little more helpful. The existing foo->dump() functionality does not
change; this patch adds foo->dumpr(). All of this is only useful when
running LLVM under a debugger.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@63736 91177308-0d34-0410-b5e6-96231b3b80d8
information. This eliminates the need for the Flags field in MemSDNode,
so this makes LoadSDNode and StoreSDNode smaller. Also, it makes
FoldingSetNodeIDs for loads and stores two AddIntegers smaller.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@63577 91177308-0d34-0410-b5e6-96231b3b80d8
crashes or wrong code with codegen of large integers:
eliminate the legacy getIntegerVTBitMask and
getIntegerVTSignBit methods, which returned their
value as a uint64_t, so couldn't handle huge types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@63494 91177308-0d34-0410-b5e6-96231b3b80d8
returned by getShiftAmountTy may be too small
to hold shift values (it is an i8 on x86-32).
Before and during type legalization, use a large
but legal type for shift amounts: getPointerTy;
afterwards use getShiftAmountTy, fixing up any
shift amounts with a big type during operation
legalization. Thanks to Dan for writing the
original patch (which I shamelessly pillaged).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@63482 91177308-0d34-0410-b5e6-96231b3b80d8
- Modify TableGen to add the DebugLoc when calling getTargetNode.
(The light-weight wrappers are only temporary. The non-DebugLoc version will be
removed once the whole debug info stuff is finished with.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@63273 91177308-0d34-0410-b5e6-96231b3b80d8
a uint64_t to verify that the value is in range for the given type,
to help catch accidental overflow. Fix a few places that relied on
getConstant implicitly truncating the value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@63128 91177308-0d34-0410-b5e6-96231b3b80d8
tidy up SDUse and related code.
- Replace the operator= member functions with a set method, like
LLVM Use has, and variants setInitial and setNode, which take
care up updating use lists, like LLVM Use's does. This simplifies
code that calls these functions.
- getSDValue() is renamed to get(), as in LLVM Use, though most
places can either use the implicit conversion to SDValue or the
convenience functions instead.
- Fix some more node vs. value terminology issues.
Also, eliminate the one remaining use of SDOperandPtr, and
SDOperandPtr itself.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@62995 91177308-0d34-0410-b5e6-96231b3b80d8
of each use in the SelectionDAG ReplaceAllUses* functions. Thanks
to Chris for spotting this opportunity.
Also, factor out code from all 5 of the ReplaceAllUses* functions
into AddNonLeafNodeToCSEMaps, which is now renamed
AddModifiedNodeToCSEMaps to more accurately reflect its purpose.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@62964 91177308-0d34-0410-b5e6-96231b3b80d8
testcase from PR3376, and in fact is sufficient to completely
avoid the problem in that testcase.
There's an underlying problem though; TLI.isOperationLegal
considers Custom to be Legal, which might be ok in some
cases, but that's what DAGCombiner is using in many places
to test if something is legal when LegalOperations is true.
When DAGCombiner is running after legalize, this isn't
sufficient. I'll address this in a separate commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@62860 91177308-0d34-0410-b5e6-96231b3b80d8
Simplify x+0 to x in unsafe-fp-math mode. This avoids a bunch of
redundant work in many cases, because in unsafe-fp-math mode,
ISD::FADD with a constant is considered free to negate, so the
DAGCombiner often negates x+0 to -0-x thinking it's free, when
in reality the end result is -x, which is more expensive than x.
Also, combine x*0 to 0.
This fixes PR3374.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@62789 91177308-0d34-0410-b5e6-96231b3b80d8
corresponding to the "not" and "vnot" PatFrags. Use the new method
in some places where it seems appropriate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@62768 91177308-0d34-0410-b5e6-96231b3b80d8
SDNode subclasses to keep state that requires non-trivial
destructors, however it was already effectively impossible,
since the destructor isn't actually ever called. There currently
aren't any SDNode subclasses affected by this, and in general
it's desireable to keep SDNode objects light-weight.
This eliminates the last virtual member function in the SDNode
class, so it eliminates the need for a vtable pointer, making
SDNode smaller.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@62539 91177308-0d34-0410-b5e6-96231b3b80d8
uses are added to the From node while it is processing From's
use list, because of automatic local CSE. The fix is to avoid
visiting any new uses.
Fix a few places in the DAGCombiner that assumed that after
a RAUW call, the From node has no users and may be deleted.
This fixes PR3018.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@62533 91177308-0d34-0410-b5e6-96231b3b80d8
This removes all the _8, _16, _32, and _64 opcodes and replaces each
group with an unsuffixed opcode. The MemoryVT field of the AtomicSDNode
is now used to carry the size information. In tablegen, the size-specific
opcodes are replaced by size-independent opcodes that utilize the
ability to compose them with predicates.
This shrinks the per-opcode tables and makes the code that handles
atomics much more concise.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61389 91177308-0d34-0410-b5e6-96231b3b80d8
target-independent way of determining overflow on multiplication. It's very
tricky. Patch by Zoltan Varga!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60800 91177308-0d34-0410-b5e6-96231b3b80d8
essential problem was that the DAG can contain
random unused nodes which were never analyzed.
When remapping a value of a node being processed,
such a node may become used and need to be analyzed;
however due to operands being transformed during
analysis the node may morph into a different one.
Users of the morphing node need to be updated, and
this wasn't happening. While there I added a bunch
of documentation and sanity checks, so I (or some
other poor soul) won't have to scratch their head
over this stuff so long trying to remember how it
was all supposed to work next time some obscure
problem pops up! The extra sanity checking exposed
a few places where invariants weren't being preserved,
so those are fixed too. Since some of the sanity
checking is expensive, I added a flag to turn it
on. It is also turned on when building with
ENABLE_EXPENSIVE_CHECKS=1.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60797 91177308-0d34-0410-b5e6-96231b3b80d8
Fix the shift amount when unrolling a vector shift into scalar shifts.
Fix problem in getShuffleScalarElt where it assumes that the input of
a bit convert must be a vector.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60740 91177308-0d34-0410-b5e6-96231b3b80d8
MERGE_VALUES node with only one operand, so get
rid of special code that only existed to handle
that possibility.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60349 91177308-0d34-0410-b5e6-96231b3b80d8
"It simplifies the type legalization part a bit, and produces better code by
teaching SelectionDAG about the extra bits in an i8 SADDO/UADDO node. In
essence, I spontaneously decided that on x86 this i8 boolean result would be
either 0 or 1, and on other platforms 0/1 or 0/-1, depending on whether the
platform likes it's boolean zero extended or sign extended."
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59864 91177308-0d34-0410-b5e6-96231b3b80d8
because the boolean it returns to indicate an overflow may not be treated like
as a flag. It could be stored to memory, for instance.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59780 91177308-0d34-0410-b5e6-96231b3b80d8
"ISD::ADDO". ISD::ADDO is lowered into a target-independent form that does the
addition and then checks if the result is less than one of the operands. (If it
is, then there was an overflow.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59779 91177308-0d34-0410-b5e6-96231b3b80d8
support targets that support these conversions. Users should avoid using
this node as the current targets don't generating code for it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59001 91177308-0d34-0410-b5e6-96231b3b80d8
type for the shift amount type. Add a check
that shifts and rotates use the type returned
by getShiftAmountTy for the amount. This
exposed some problems in CellSPU and PPC,
which have already been fixed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58455 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
(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
to have a different type to the vector element
type. This should be fairly harmless because in
the past guys like this were being built all over
the place (and were cleaned up when I added this
check). The reason for relaxing this check is
that it helps LegalizeTypes legalize vector
shuffles: the mask is a BUILD_VECTOR that it is
*not always possible* to legalize while keeping it
a BUILD_VECTOR (vector_shuffle requires the mask
to be a BUILD_VECTOR, as opposed to a vector with
the right vector type). With this check it is even
harder to legalize the mask - turning the check off
means that LegalizeTypes manages to legalize almost
all vector shuffles encountered in practice. The
correct solution is to change vector_shuffle to be a
variadic node with the mask built into it as operands.
While waiting for that change, this hack stops the
problem with vector_shuffle from blocking the turning
on of LegalizeTypes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@57965 91177308-0d34-0410-b5e6-96231b3b80d8
in the 32-bit signed offset field of addresses. Even though this
may be intended, some linkers refuse to relocate code where the
relocated address computation overflows.
Also, fix the sign-extension of constant offsets to use the
actual pointer size, rather than the size of the GlobalAddress
node, which may be different, for example on x86-64 where MVT::i32
is used when the address is being fit into the 32-bit displacement
field.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@57885 91177308-0d34-0410-b5e6-96231b3b80d8
and add a TargetLowering hook for it to use to determine when this
is legal (i.e. not in PIC mode, etc.)
This allows instruction selection to emit folded constant offsets
in more cases, such as the included testcase, eliminating the need
for explicit arithmetic instructions.
This eliminates the need for the C++ code in X86ISelDAGToDAG.cpp
that attempted to achieve the same effect, but wasn't as effective.
Also, fix handling of offsets in GlobalAddressSDNodes in several
places, including changing GlobalAddressSDNode's offset from
int to int64_t.
The Mips, Alpha, Sparc, and CellSPU targets appear to be
unaware of GlobalAddress offsets currently, so set the hook to
false on those targets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@57748 91177308-0d34-0410-b5e6-96231b3b80d8
`-fno-builtin' flag. Currently, it's used to replace "memset" with "_bzero"
instead of "__bzero" on Darwin10+. This arguably violates the meaning of this
flag, but is currently sufficient. The meaning of this flag should become more
specific over time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56885 91177308-0d34-0410-b5e6-96231b3b80d8
Completely eliminate the TopOrder std::vector. Instead, sort
the AllNodes list in place. This also eliminates the need to
call AllNodes.size(), a linear-time operation, before
performing the sort.
Also, eliminate the Sources temporary std::vector, since it
essentially duplicates the sorted result as it is being
built.
This also changes the direction of the topological sort
from bottom-up to top-down. The AllNodes list starts out in
roughly top-down order, so this reduces the amount of
reordering needed. Top-down is also more convenient for
Legalize, and ISel needed only minor adjustments.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56867 91177308-0d34-0410-b5e6-96231b3b80d8
its size). Adjust various lowering functions to
pass this info through from CallInst. Use it to
implement sseregparm returns on X86. Remove
X86_ssecall calling convention.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56677 91177308-0d34-0410-b5e6-96231b3b80d8
ConstantPoolSDNode, using the target's preferred alignment for the
constant type.
In LegalizeDAG, when performing loads from the constant pool, the
ConstantPoolSDNode's alignment is used in the calls to getLoad and
getExtLoad.
This change prevents SelectionDAG::getLoad/getExtLoad from incorrectly
choosing the ABI alignment for constant pool loads when Alignment == 0.
The incorrect alignment is only a performance issue when ABI alignment
does not equal preferred alignment (i.e., on x86 it was generating
MOVUPS instead of MOVAPS for v4f32 constant loads when the default ABI
alignment for 128bit vectors is forced to 1 byte.)
Patch by Paul Redmond!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56253 91177308-0d34-0410-b5e6-96231b3b80d8
- Add linkage to SymbolSDNode (default to external).
- Change ISD::ExternalSymbol to ISD::Symbol.
- Change ISD::TargetExternalSymbol to ISD::TargetSymbol
These changes pave the way to allowing SymbolSDNodes with non-external linkage.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56249 91177308-0d34-0410-b5e6-96231b3b80d8
Currently it just holds the calling convention and flags
for isVarArgs and isTailCall.
And it has several utility methods, which eliminate magic
5+2*i and similar index computations in several places.
CallSDNodes are not CSE'd. Teach UpdateNodeOperands to handle
nodes that are not CSE'd gracefully.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56183 91177308-0d34-0410-b5e6-96231b3b80d8
ConstantFP* instead of APInt and APFloat directly.
This reduces the amount of time to create ConstantSDNode
and ConstantFPSDNode nodes when ConstantInt* and ConstantFP*
respectively are already available, as is the case in
SelectionDAGBuild.cpp. Also, it reduces the amount of time
to legalize constants into constant pools, and the amount of
time to add ConstantFP operands to MachineInstrs, due to
eliminating ConstantInt::get and ConstantFP::get calls.
It increases the amount of work needed to create new constants
in cases where the client doesn't already have a ConstantInt*
or ConstantFP*, such as legalize expanding 64-bit integer constants
to 32-bit constants. And it adds a layer of indirection for the
accessor methods. But these appear to be outweight by the benefits
in most cases.
It will also make it easier to make ConstantSDNode and
ConstantFPNode more consistent with ConstantInt and ConstantFP.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56162 91177308-0d34-0410-b5e6-96231b3b80d8
with ConstantInt. This led to fixing a bug in TargetLowering.cpp
using getValue instead of getAPIntValue.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56159 91177308-0d34-0410-b5e6-96231b3b80d8
ATOMIC_LOAD_ADD_{8,16,32,64} instead of ATOMIC_LOAD_ADD.
Increased the Hardcoded Constant OpActionsCapacity to match.
Large but boring; no functional change.
This is to support partial-word atomics on ppc; i8 is
not a valid type there, so by the time we get to lowering, the
ATOMIC_LOAD nodes looks the same whether the type was i8 or i32.
The information can be added to the AtomicSDNode, but that is the
largest SDNode; I don't fully understand the SDNode allocation,
but it is sensitive to the largest node size, so increasing
that must be bad. This is the alternative.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55457 91177308-0d34-0410-b5e6-96231b3b80d8
works with.
SelectionDAG, FunctionLoweringInfo, and SelectionDAGLowering
objects now get created once per SelectionDAGISel instance, and
can be reused across blocks and across functions. Previously,
they were created and destroyed each time they were needed.
This reorganization simplifies the handling of PHI nodes, and
also SwitchCases, JumpTables, and BitTestBlocks. This
simplification has the side effect of fixing a bug in FastISel
where successor PHI nodes weren't being updated correctly.
This is also a step towards making the transition from FastISel
into and out of SelectionDAG faster, and also making
plain SelectionDAG faster on code with lots of little blocks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55450 91177308-0d34-0410-b5e6-96231b3b80d8
