Displaying 9 results from an estimated 9 matches for "processblock".
2010 Apr 13
3
[LLVMdev] VMKit assertion failure
Hi Eli,
I know the pass that fails, it is MachineCSE. It stack overflows because
there are too many recursive calls to processBlock (line 362 of
lib/CodeGen/MachineCSE.cpp). But the recursion is here on purpose, and I am
sure there are other places where LLVM makes recursive calls. Or is
recursion forbidden in LLVM, and explicitly stated to be so?
Cheers,
Nicolas
On Tue, Apr 13, 2010 at 5:56 PM, Eli Friedman <eli.friedman...
2010 Apr 13
0
[LLVMdev] VMKit assertion failure
On Tue, Apr 13, 2010 at 9:33 AM, nicolas geoffray
<nicolas.geoffray at gmail.com> wrote:
> Hi Eli,
> I know the pass that fails, it is MachineCSE. It stack overflows because
> there are too many recursive calls to processBlock (line 362 of
> lib/CodeGen/MachineCSE.cpp). But the recursion is here on purpose, and I am
> sure there are other places where LLVM makes recursive calls. Or is
> recursion forbidden in LLVM, and explicitly stated to be so?
Unbounded recursion is generally considered a bug; please file....
2016 Jun 10
2
Early CSE clobbering llvm.assume
...t;
bool GVN::processAssumeIntrinsic(IntrinsicInst *Inst) {
...
// We can replace assume value with true, which covers cases like this:
// call void @llvm.assume(i1 %cmp)
// br i1 %cmp, label %bb1, label %bb2 ; will change %cmp to true
ReplaceWithConstMap[V] = True;
...
}
...
bool GVN::processBlock(BasicBlock *BB) {
...
// Clearing map before every BB because it can be used only for single
BB.
ReplaceWithConstMap.clear();
....
}
So it's going to go through the rest of the bb, see nothing with %2, do
nothing, and then next iteration, clear the constant map. It's not valid
to...
2016 Jun 10
3
Early CSE clobbering llvm.assume
...e can replace assume value with true, which covers cases like this:
>> // call void @llvm.assume(i1 %cmp)
>> // br i1 %cmp, label %bb1, label %bb2 ; will change %cmp to true
>> ReplaceWithConstMap[V] = True;
>> ...
>> }
>>
>> ...
>> bool GVN::processBlock(BasicBlock *BB) {
>> ...
>> // Clearing map before every BB because it can be used only for single
>> BB.
>> ReplaceWithConstMap.clear();
>> ....
>>
>> }
>>
>>
>> So it's going to go through the rest of the bb, see nothing with %...
2010 Apr 13
0
[LLVMdev] VMKit assertion failure
On Tue, Apr 13, 2010 at 2:29 AM, Konrad Hinsen
<konrad.hinsen at fastmail.net> wrote:
> On 11.04.2010, at 19:14, nicolas geoffray wrote:
>
>> On Sun, Apr 11, 2010 at 7:12 PM, Konrad Hinsen <konrad.hinsen at fastmail.net> wrote
>>> I am rather surprised that the size of a method should have an impact on stack usage, but then I haven't looked at all at how VMKit
2010 Apr 13
2
[LLVMdev] VMKit assertion failure
On 11.04.2010, at 19:14, nicolas geoffray wrote:
> On Sun, Apr 11, 2010 at 7:12 PM, Konrad Hinsen <konrad.hinsen at fastmail.net> wrote
>> I am rather surprised that the size of a method should have an impact on stack usage, but then I haven't looked at all at how VMKit works yet. That's my next project :-)
>>
> It has no impact on VMKit. The impact is on LLVM
2016 Jun 10
4
Early CSE clobbering llvm.assume
As of llvm 3.8, the early CSE pass seems to remove llvm.assume intrinsics.
Is this the expected behavior?
I've attached as small-ish example of this happening in my production code.
$ opt -early-cse before-early-cse.ll -S > after-early-cse.ll
Note the use of the assume intrinsic indicating that the loaded value
%channels equals 3. In a later pass I replace the load instruction with
2015 Jul 21
6
[LLVMdev] GlobalsModRef (and thus LTO) is completely broken
...0a1a20c8)
> + 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.dylib`(anonymous
> namespace)::GVN::processBlock(this=0x000000010e6ce680,
> BB=0x000000010a19ffa0) + 251 at GVN.cpp:2394
> frame #11: 0x0000000103401755 libLTO.dylib`(anonymous
> namespace)::GVN::iterateOnFunction(this=0x000000010e6ce680,
> F=0x00000001085f69f8) + 1541 at GVN.cpp:2677
> frame #12: 0x0000000103400fef libLTO....
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