Displaying 5 results from an estimated 5 matches for "processload".
2014 May 15
4
[LLVMdev] SROA is slow when compiling a large basic block
...cally
replaces Instruction's pointer to its parent BasicBlock with another data
structure. I haven't done much investigation into how this will affect the
common case.
This will also help speed up the execution of code in other places. For
example, these two functions are called when GVN::processLoad is called and
iterate over a basic block's instruction list to determine the order of two
(load and stores) instructions.:
llvm::isPotentiallyReachable
// Linear scan, start at 'A', see whether we hit 'B' or the end first.
for (BasicBlock::const_iterator I = A, E =...
2014 May 15
2
[LLVMdev] SROA is slow when compiling a large basic block
...9;s pointer to its parent BasicBlock with another data
> structure. I haven't done much investigation into how this will affect the
> common case.
>
>
> This will also help speed up the execution of code in other places. For
> example, these two functions are called when GVN::processLoad is called and
> iterate over a basic block's instruction list to determine the order of two
> (load and stores) instructions.:
>
>
> llvm::isPotentiallyReachable
>
>
> // Linear scan, start at 'A', see whether we hit 'B' or the end
> first.
>...
2015 Aug 07
2
load instruction erroneously removed by GVN
...format_long(i16* %_tmp30, i16 10, i32 10), !dbg !22
call fastcc void @check_i(i16 2, i16 undef, i16 48), !dbg !24
ret i16 0, !dbg !25
}
So GVN has deemed
%_tmp33 = load i16, i16* %_tmp32, align 1, !dbg !24
useless, and removed it, replacing %_tmp33 with undef.
While examining the load, processLoad does
MemDepResult Dep = MD->getDependency(L);
[...]
Instruction *DepInst = Dep.getInst();
[...]
// If this load really doesn't depend on anything, then we must be
loading an
// undef value. This can happen when loading for a fresh allocation
with no
// intervening st...
2015 Jul 21
6
[LLVMdev] GlobalsModRef (and thus LTO) is completely broken
...gt; MemoryDependenceAnalysis.cpp:911
> frame #7: 0x000000010340c5b5 libLTO.dylib`(anonymous
> namespace)::GVN::processNonLocalLoad(this=0x000000010e6ce680,
> LI=0x000000010a1a20c8) + 101 at GVN.cpp:1706
> frame #8: 0x0000000103408eef libLTO.dylib`(anonymous
> namespace)::GVN::processLoad(this=0x000000010e6ce680, L=0x000000010a1a20c8)
> + 1551 at GVN.cpp:1905
> frame #9: 0x00000001034080fd libLTO.dylib`(anonymous
> namespace)::GVN::processInstruction(this=0x000000010e6ce680,
> I=0x000000010a1a20c8) + 397 at GVN.cpp:2220
> frame #10: 0x0000000103407d1b libLTO.d...
2015 Jul 17
2
[LLVMdev] GlobalsModRef (and thus LTO) is completely broken
On Fri, Jul 17, 2015 at 9:13 AM Evgeny Astigeevich <
evgeny.astigeevich at arm.com> wrote:
> It’s Dhrystone.
>
Dhrystone has historically not been a good indicator of real-world
performance fluctuations, especially at this small of a shift.
I'd like to see if we see any fluctuation on larger and more realistic
application benchmarks. One advantage of the flag being set is that we