Displaying 10 results from an estimated 10 matches for "unwindinst".
Did you mean:
unwinding
2011 Jul 27
2
[LLVMdev] LLVMdev Digest, Vol 85, Issue 50
On Jul 27, 2011, at 11:10 AM, John McCall wrote:
>>
>> 6) it would be nice if the existing UnwindInst could be retained. I wince at naming an instruction
>> "Resume" since in the English language it is so ambiguous (resume normal execution following
>> the conclusion of handing an exception, verses resume throwing an exception). IE cosmetics
>> do matter.
>
> I...
2007 Apr 06
1
[LLVMdev] Integrating LLVM in an existing project
...eds more work.
Also, I suppose you might need to uncomment this bit in llvm-backend.cpp
as well:
// Disabled until PR1224 is resolved.
//if (flag_exceptions)
// Args.push_back("--enable-eh");
Some comments on the patch:
(1)
new UnreachableInst(CurBB);
+ } else {
+ new UnwindInst(UnwindBB);
}
-#endif
+#else
new UnwindInst(UnwindBB);
+#endif
This avoid generating an unwind instruction straight after an unreachable
instruction, i.e. two terminators in a row.
(2)
- FuncCPPPersonality = cast<Function>(
+ FuncCPPPersonality =
TheModule->getOrInsertFu...
2007 Apr 06
0
[LLVMdev] Integrating LLVM in an existing project
On Fri, 6 Apr 2007, Nicolas Geoffray wrote:
> Like you say, it's not functional for non-calls instructions. Besides,
> having to change all CalInst to InvokeInst is just too much pain in our
> current vm.
ok.
> Actually, why is it missing? What's the difference between the code
> generator and the JIT?
There are two things missing:
1. Testing and working out the set
2007 Apr 06
2
[LLVMdev] Integrating LLVM in an existing project
Hi Chris,
Chris Lattner wrote:
>> We can not use current exception handling in llvm, see
>> http://www.nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt.
>>
>
> Why not?
>
>
Like you say, it's not functional for non-calls instructions. Besides,
having to change
all CalInst to InvokeInst is just too much pain in our current vm.
> There are two
2011 Jul 27
5
[LLVMdev] LLVMdev Digest, Vol 85, Issue 50
...finally the
already decoded value is used to "switch" from the landing pad to the
correct catch-block.
who is going to generate all that code, is it still going to be
explicit in the IR, or is CodeGen going
to now be responsible creating it.
6) it would be nice if the existing UnwindInst could be retained. I
wince at naming an instruction
"Resume" since in the English language it is so ambiguous (resume
normal execution following
the conclusion of handing an exception, verses resume throwing an
exception). IE cosmetics
do matter.
7) there are still lots of oth...
2011 Jul 28
0
[LLVMdev] LLVMdev Digest, Vol 85, Issue 50
...rom the landing pad to the correct catch-block.
>
> who is going to generate all that code, is it still going to be explicit in the IR, or is CodeGen going
> to now be responsible creating it.
>
It will be explicit in the IR, as it is now. :)
> 6) it would be nice if the existing UnwindInst could be retained. I wince at naming an instruction
> "Resume" since in the English language it is so ambiguous (resume normal execution following
> the conclusion of handing an exception, verses resume throwing an exception). IE cosmetics
> do matter.
>
The UnwindInst car...
2011 Jul 27
0
[LLVMdev] LLVMdev Digest, Vol 85, Issue 50
...t;switch" from the landing pad to the correct catch-block.
>
> who is going to generate all that code, is it still going to be explicit in the IR, or is CodeGen going
> to now be responsible creating it.
It will still be explicit in the IR.
> 6) it would be nice if the existing UnwindInst could be retained. I wince at naming an instruction
> "Resume" since in the English language it is so ambiguous (resume normal execution following
> the conclusion of handing an exception, verses resume throwing an exception). IE cosmetics
> do matter.
I would be fine with st...
2011 Jul 27
0
[LLVMdev] LLVMdev Digest, Vol 85, Issue 50
On Jul 27, 2011, at 11:17 AM, Chris Lattner wrote:
> On Jul 27, 2011, at 11:10 AM, John McCall wrote:
>>> 6) it would be nice if the existing UnwindInst could be retained. I wince at naming an instruction
>>> "Resume" since in the English language it is so ambiguous (resume normal execution following
>>> the conclusion of handing an exception, verses resume throwing an exception). IE cosmetics
>>> do matter....
2007 Dec 10
2
[LLVMdev] Exception handling in JIT
...tch that enables exception handling when jitting. I've
copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may need
to factorize it, but the functionality is there and I'm very happy with
it :)
lli should now be able to execute the output from llvm-gcc when using
exceptions (the UnwindInst instruction is not involved in this patch).
Just add the -enable-eh command line argument.
There is room for improvement here: I generate a common EH frame table
and an EH frame table for each generated function. The common EH frame
table should be shared between functions with the same personalit...
2007 Dec 11
0
[LLVMdev] Exception handling in JIT
...and I'm very happy
> with
> it :)
Very nice! I don't know enough about EH, someone else please review.
It does look like it's in need of some refactoring. How much work is it?
>
> lli should now be able to execute the output from llvm-gcc when using
> exceptions (the UnwindInst instruction is not involved in this patch).
> Just add the -enable-eh command line argument.
>
> There is room for improvement here: I generate a common EH frame table
> and an EH frame table for each generated function. The common EH frame
> table should be shared between functions...