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
LoopPass*.
- Although less precise, this means they can be used in clients
without RTTI (who would otherwise need to include LoopPass.h, which
eventually includes things using dynamic_cast). This was the
simplest solution that presented itself, but I am happy to use a
better one if available.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58010 91177308-0d34-0410-b5e6-96231b3b80d8
to find opportunities for store-to-load forwarding or load CSE,
in the same way that visitStore scans back to do DSE. Also, define
a new helper function for testing whether the addresses of two
memory accesses are known to have the same value, and use it in
both visitStore and visitLoad.
These two changes allow instcombine to eliminate loads in code
produced by front-ends that frequently emit obviously redundant
addressing for memory references.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@57608 91177308-0d34-0410-b5e6-96231b3b80d8
- Renumber fcmp predicates to match their icmp counterparts.
- Try swapping operands to expose more optimization opportunities.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@57513 91177308-0d34-0410-b5e6-96231b3b80d8
This includes not marking a GEP involving a vector as unsafe, but only when it
has all zero indices. This allows scalarrepl to work in a few more cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@57177 91177308-0d34-0410-b5e6-96231b3b80d8
shifting and masking inside a bswap expr. This allows it to handle
the cases from PR2842, which involve the intermediate 'or'
expressions being shifted, not just the input value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@57095 91177308-0d34-0410-b5e6-96231b3b80d8
when deciding whether to mark a function readnone/readonly.
Since the pass is currently run before SROA, this may be
quite helpful. Requested by Chris on IRC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@57050 91177308-0d34-0410-b5e6-96231b3b80d8
pointer bitcasts and GEP's", and centralize the
logic in Value::getUnderlyingObject. The
difference with stripPointerCasts is that
stripPointerCasts only strips GEPs if all
indices are zero, while getUnderlyingObject
strips GEPs no matter what the indices are.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56922 91177308-0d34-0410-b5e6-96231b3b80d8
- return attributes - inreg, zext and sext
- parameter attributes
- function attributes - nounwind, readonly, readnone, noreturn
Return attributes use 0 as the index.
Function attributes use ~0U as the index.
This patch requires corresponding changes in llvm-gcc and clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56704 91177308-0d34-0410-b5e6-96231b3b80d8
s/ParamAttr/Attribute/g
s/PAList/AttrList/g
s/FnAttributeWithIndex/AttributeWithIndex/g
s/FnAttr/Attribute/g
This sets the stage
- to implement function notes as function attributes and
- to distinguish between function attributes and return value attributes.
This requires corresponding changes in llvm-gcc and clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56622 91177308-0d34-0410-b5e6-96231b3b80d8
