Doesn't make sense to restrict this to BumpPtrAllocator. While there
replace an explicit loop with std::equal. Some standard libraries know
how to compile this down to a ::memcmp call if possible.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206615 91177308-0d34-0410-b5e6-96231b3b80d8
Still only 32-bit ARM using it at this stage, but the promotion allows
direct testing via opt and is a reasonably self-contained patch on the
way to switching ARM64.
At this point, other targets should be able to make use of it without
too much difficulty if they want. (See ARM64 commit coming soon for an
example).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206485 91177308-0d34-0410-b5e6-96231b3b80d8
ARM64 suffered multiple -verify-machineinstr failures (principally over the
xsp/xzr issue) because FastISel was completely ignoring which subset of the
general-purpose registers each instruction required.
More fixes are coming in ARM64 specific FastISel, but this should cover the
generic problems.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206283 91177308-0d34-0410-b5e6-96231b3b80d8
Moves redundant template parameters into an implementation detail of
BlockFrequencyInfoImpl.
No functionality change.
<rdar://problem/14292693>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206084 91177308-0d34-0410-b5e6-96231b3b80d8
This is a shared implementation class for BlockFrequencyInfo and
MachineBlockFrequencyInfo, not for BlockFrequency, a related (but
distinct) class.
No functionality change.
<rdar://problem/14292693>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206083 91177308-0d34-0410-b5e6-96231b3b80d8
This removes the -segmented-stacks command line flag in favor of a
per-function "split-stack" attribute.
Patch by Luqman Aden and Alex Crichton!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205997 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r205974, it turns out that this wasn't such a great idea
after all. Using DIVariable as return value is self-documenting and marginally
more type safe.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205979 91177308-0d34-0410-b5e6-96231b3b80d8
Makes iteration over implicit and explicit machine operands more
explicit (har har). Insipired by code review discussion for r205565.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205680 91177308-0d34-0410-b5e6-96231b3b80d8
Member functions defined within a class definition are implicitly
'inline' for linkage purposes. Compilers might slightly favor inlining
functions explicitly marked 'inline', but LLVM doesn't make a stylistic
habit of doing this generally.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205679 91177308-0d34-0410-b5e6-96231b3b80d8
This commit updates the stackmap format to version 1 to indicate the
reorganizaion of several fields. This was done in order to align stackmap
entries to their natural alignment and to minimize padding.
Fixes <rdar://problem/16005902>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205254 91177308-0d34-0410-b5e6-96231b3b80d8
This is a necessary step to lifting some of its configuration into
template parameters rather than runtime parameters.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205140 91177308-0d34-0410-b5e6-96231b3b80d8
ARM64 for iOS is going to want to emit these symbols in a
linker-private style for efficiency, but other targets probably don't
want that behaviour.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205080 91177308-0d34-0410-b5e6-96231b3b80d8
* Use assignment instead of swap (since the original value is being
destroyed anyway)
* Rename "updateAdjEdgeId" to "setAdjEdgeId"
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204983 91177308-0d34-0410-b5e6-96231b3b80d8
The edge data structure (EdgeEntry) now holds the indices of its entries in the
adjacency lists of the nodes it connects. This trades a little ugliness for
faster insertion/removal, which is now O(1) with a cheap constant factor. All
of this is implementation detail within the PBQP graph, the external API remains
unchanged.
Individual register allocations are likely to change, since the adjacency lists
will now be ordered differently (or rather, will now be unordered). This
shouldn't affect the average quality of allocations however.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204841 91177308-0d34-0410-b5e6-96231b3b80d8
Implement Pass::releaseMemory() in BlockFrequencyInfo and
MachineBlockFrequencyInfo. Just delete the private implementation when
not in use. Switch to a std::unique_ptr to make the logic more clear.
<rdar://problem/14292693>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204741 91177308-0d34-0410-b5e6-96231b3b80d8
This patch renames method 'isConstantSplat' as 'getConstantSplatValue'
(mainly for consistency reasons), and rewrites its logic to ensure
that we always perform a legal 'cast<ConstantSDNode>'.
Added test shift-combine-crash.ll to verify that DAGCombiner no longer crashes with an assertion failure in the attempt to simplify a vector shift by a vector of all undef counts.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204536 91177308-0d34-0410-b5e6-96231b3b80d8
Rather than LegalizeAction::Expand, this needs LegalizeAction::Promote to get
promoted to fp_to_sint v8f32->v8i32. This is a legal operation on AVX.
For that to work properly, we also need to teach the legalizer about the
specific promotion required here. The default vector promotion uses
bitcasting to a vector type of the same total size. We want to promote the
vector element type, effectively widening the operation and then truncating
the result. This is analogous to the current logic of how int_to_fp is
promoted.
The change also factors out some code from the int_to_fp promotion code to
ValueType::widenIntegerVectorElementType. This is now shared between
int_to_fp and fp_to_int.
There is no longer need for the custom lowering of fp_to_sint f32->v8i16 in
X86. It can now go through the new target-independent fp_to_*int promotion
logic.
I also checked that no other target uses Promote for these ops yet, so there
shouldn't be any unexpected change in behavior.
Fixes <rdar://problem/16202247>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204058 91177308-0d34-0410-b5e6-96231b3b80d8
