1. Allocate them in the entry block of the function to enable function-wide
re-use. The instructions to create them should be re-materializable, so
there shouldn't be additional cost compared to creating them local
to the basic blocks where they are used.
2. Collect all of the frame index references for the function and sort them
by the local offset referenced. Iterate over the sorted list to
allocate the virtual base registers. This enables creation of base
registers optimized for positive-offset access of frame references.
(Note: This may be appropriate to later be a target hook to do the
sorting in a target appropriate manner. For now it's done here for
simplicity.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112609 91177308-0d34-0410-b5e6-96231b3b80d8
any more. I plan to reimplement alloca promotion using SSAUpdater later.
It looks like Bill's URoR logic really always needs domtree, so the pass
now always asks for domtree info.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112597 91177308-0d34-0410-b5e6-96231b3b80d8
two are weak, we make them thunks to a new strong function) so don't iterate
through the function list as we're modifying it.
Also add back the outermost loop which got removed during the cleanups.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112595 91177308-0d34-0410-b5e6-96231b3b80d8
This actually exposed an infinite recursion bug in ComputeValueKnownInPredecessors which theoretically already existed (in JumpThreading's
handling of and/or of i1's), but never manifested before. This patch adds a tracking set to prevent this case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112589 91177308-0d34-0410-b5e6-96231b3b80d8
getMagicNumber was treating the _binary_ data it read in as a
null terminated string. This resulted in the std::string
calculating the length, and causing an assert in other code that
assumed that the length it passed was the same as the length of
the string it would get back.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112586 91177308-0d34-0410-b5e6-96231b3b80d8
where we hash, compare and fold, instead of one iteration where we build up
the hash buckets and a second one to fold.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112582 91177308-0d34-0410-b5e6-96231b3b80d8
Eventually, we want to disable physreg coalescing completely, and let the
register allocator do its job using hints.
This option makes it possible to measure the impact of disabling physreg
coalescing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112567 91177308-0d34-0410-b5e6-96231b3b80d8
kill flag.
This could cause duplicate kill flags when the same register was used twice in a
continuous sequence of STRs.
There is no small test case. <rdar://problem/8218046>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112534 91177308-0d34-0410-b5e6-96231b3b80d8
help relieve register pressure a bit. Recalculating the local address is
almost always going to be better than spilling.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112503 91177308-0d34-0410-b5e6-96231b3b80d8
1) nuke ConstDataCoalSection, which is dead.
2) revise my previous patch for rdar://8018335,
which was completely wrong. Specifically, it doesn't
make sense to mark __TEXT,__const_coal as PURE_INSTRUCTIONS,
because it is for readonly data. templates (it turns out)
go to const_coal_nt. The real fix for rdar://8018335 was
to give ConstTextCoalSection a section kind of ReadOnly
instead of Text.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112496 91177308-0d34-0410-b5e6-96231b3b80d8
operand is killed, add it to the expanded instruction as an implicit kill
operand instead of marking the individual subregs with kill flags. This
should work better in general and also handles the case for VST3 where one
of the subregs was not referenced in the expanded instruction and so was
not marked killed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112494 91177308-0d34-0410-b5e6-96231b3b80d8
Unfortunately, the only testcase I have for this is huge and doesn't reduce well because the error is
sensitive to iteration-order issues, since the problem only occurs when merging values in a particular order.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112489 91177308-0d34-0410-b5e6-96231b3b80d8
On Mingw and Cygwin, the symbol __main is resolved to
callee's(eg. tools/lli) one, to invoke wrong duplicated ctors
(and register wrong callee's dtors with atexit(3)).
We expect, by callee, ExecutionEngine::runStaticConstructorsDestructors()
is called before ExecutionEngine::runFunctionAsMain() is called.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112474 91177308-0d34-0410-b5e6-96231b3b80d8
