Displaying 3 results from an estimated 3 matches for "addressingmodematcher".
2012 Nov 19
1
[LLVMdev] OptimizeMemoryInst(...) scaling
...pare::OptimizeMemoryInst(...) has attracted anyone's attention
already. If so, any insight into this problem would be appreciated.
If it helps, it's clear that the lion's share of time spent
in OptimizeMemoryInst(...) is actually spent matching the address mode of
the loads/stores with AddressingModeMatcher::MatchAddr(...).
Thanks,
Cameron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121119/d59a07df/attachment.html>
2014 May 21
5
[LLVMdev] [CodeGenPrepare] Sinking incoming values of a PHI Node
Hi,
I want to improve the way CGP sinks the incoming values of a PHI node
towards memory accesses. Improving it means a lot to some of our key
benchmarks, and I believe can benefit many general cases as well.
CGP's OptimizeMemoryInst function handles PHI nodes by running
AddressingModeMatcher on all incoming values to see whether they reach
consensus on the addressing mode. It does a reasonably good job in sinking
a PHI node if its incoming values are used only once (by the PHI node) and
share the same base register and offset. For example, CGP transforms
define void @foo(i1 %cond, flo...
2011 May 06
0
[LLVMdev] Question about linking llvm-mc when porting a new backend
...pe const*,
unsigned int)in libLLVMAnalysis.a(ScalarEvolution.cpp.o)
llvm::FastISel::SelectGetElementPtr(llvm::User const*)in
libLLVMSelectionDAG.a(FastISel.cpp.o)
computeArraySize(llvm::CallInst const*, llvm::TargetData const*,
bool)in libLLVMAnalysis.a(MemoryBuiltins.cpp.o)
llvm::AddressingModeMatcher::MatchOperationAddr(llvm::User*, unsigned
int, unsigned int)in libLLVMTransformUtils.a(AddrModeMatcher.cpp.o)
llvm::ComputeMaskedBits(llvm::Value*, llvm::APInt const&,
llvm::APInt&, llvm::APInt&, llvm::TargetData const*, unsigned int)in
libLLVMAnalysis.a(ValueTracking.cpp.o)...