Displaying 20 results from an estimated 200 matches similar to: "[LLVMdev] Non-local DSE optimization"
2009 Sep 03
2
[LLVMdev] Non-local DSE optimization
Hi,
It looks like PDT.getRootNode() returns NULL for:
define fastcc void @c974001__lengthy_calculation.
1736(%struct.FRAME.c974001* nocapture %CHAIN.185) noreturn {
entry:
br label %bb
bb:
br label %bb
}
Isn't it a bug in PostDominatorTree?
Please note that this crashes:
opt -postdomtree -debug dom_crash.bc
I think this should be reported as a bug,
-Jakub
On Sep 3, 2009, at
2009 Sep 03
0
[LLVMdev] Non-local DSE optimization
Hi Jakub, interesting patch. I ran it over the Ada testsuite and this
picked up some problems even without enabling dse-ssu. For example,
"opt -inline -dse -domtree" crashes on the attached testcase.
Ciao,
Duncan.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dom_crash.ll
URL:
2009 Sep 06
0
[LLVMdev] Non-local DSE optimization
Jakub Staszak wrote:
> Hi,
>
> It looks like PDT.getRootNode() returns NULL for:
>
> define fastcc void @c974001__lengthy_calculation.
> 1736(%struct.FRAME.c974001* nocapture %CHAIN.185) noreturn {
> entry:
> br label %bb
>
> bb:
> br label %bb
> }
>
>
> Isn't it a bug in PostDominatorTree?
>
> Please note that this crashes:
>
2009 Sep 08
2
[LLVMdev] Non-local DSE optimization
Hello,
Bug is already fixed by Chris (see: http://llvm.org/bugs/show_bug.cgi?id=4915)
.
I added getRootNode() == NULL condition to my patch. It's not a great
solution, but it is enough for now I think. New patch attached.
-Jakub
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dse_ssu-2.patch
Type: application/octet-stream
Size: 17762 bytes
Desc: not
2010 Dec 01
8
[LLVMdev] Alternative exception handling proposal
Here is an alternative proposal to Bill's. It is closer to what we already
have (which can be seen as a good or a bad thing!), and is also closer to
what gcc does. It is more incremental than Bill's and introduces fewer
new concepts.
Executive summary
-----------------
Remove the personality and list of catches out of eh.selector and stick them
directly on invoke instructions.
The
2010 Dec 07
0
[LLVMdev] RFC: Exception Handling Proposal Revised
Hi Bill, there are a couple of things I didn't understand about your proposal,
for example how it interacts with inlining, whether it is feasible to do the
"turn invoke-of-Unwind_Resume into a branch" optimization and also whether in
"resumedest" you still plan to use _Unwind_Resume to continue unwinding up the
stack. Could you please show what the LLVM IR would look like
2010 Dec 01
10
[LLVMdev] RFC: Exception Handling Proposal Revised
This is a revision of the second exception handling proposal I sent out. You can see it here:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-November/036484.html
After much discussion, there are some changes to the proposal – some significant and some minor. One major point, this proposal does not address the issue of catching an exception thrown from a non-invoke instruction. However if done
2009 Mar 26
2
[LLVMdev] how to get the InvodInst 's Operand Name?
HI all,
here is a llvm IR :
invoke void @__cxa_throw(i8* %7, i8* bitcast
(%struct.__fundamental_type_info_pseudo* @_ZTIi to i8*), void (i8*)*
null)
noreturn to label %invcont unwind label %lpad
say I want to get the Invoke's Operand's name, I use
getOperand(i)->getName(), it can work for that the Operand hasname,
but some Operand hasn't name,
So, My problem is how
2009 Mar 26
2
[LLVMdev] how to get the InvodInst 's Operand Name?
Hi Duncan,
>>are you trying to get the name "@_ZTIi" or "@__cxa_throw"?
yes! i want get the name @_ZTi or @__cxa_throw,
the latter @__cxa_throw i can get it throw value->getName(), but the
@_ZTi it did n't has name!
zhangzw
thanks
2009/3/26 Duncan Sands <baldrick at free.fr>:
> Hi zhangzw,
>
>> invoke void @__cxa_throw(i8* %7, i8*
2010 Dec 01
0
[LLVMdev] RFC: Exception Handling Proposal Revised
Hi Bill, this proposal seems strangely complicated. I don't see the advantage
of the dispatch instruction over just attaching the information to each invoke.
Right now you have
invoke void @_Z3foov()
to label %invcont unwind label %catch.handlers
catch.handlers: landingpad
dispatch resume to label %...
catches [
%struct.__fundamental_type_info_pseudo* @_ZTIi, label
2009 May 12
1
[LLVMdev] How distinguish Catch all llvm-IR from other catch type ?
Hi,
catch_all.cpp:
1 int main()
2 {
3 try {
4 throw 34;
5 }
6 catch (...) {}
7 }
llvm-gcc -O3 -S -emit-llvm catch_all.cpp -o catch_all.ll:
1 ; ModuleID = 'catch_all.cpp'
2 target datalayout =
2010 Dec 01
2
[LLVMdev] RFC: Exception Handling Proposal Revised
On Dec 1, 2010, at 10:20 AM, Duncan Sands wrote:
> Hi Bill, this proposal seems strangely complicated. I don't see the advantage
> of the dispatch instruction over just attaching the information to each invoke.
> Right now you have
>
> invoke void @_Z3foov()
> to label %invcont unwind label %catch.handlers
>
> catch.handlers: landingpad
> dispatch resume
2009 Mar 26
0
[LLVMdev] how to get the InvodInst 's Operand Name?
Hi zhangzw,
> invoke void @__cxa_throw(i8* %7, i8* bitcast
> (%struct.__fundamental_type_info_pseudo* @_ZTIi to i8*), void (i8*)*
> null)
> noreturn to label %invcont unwind label %lpad
>
> say I want to get the Invoke's Operand's name
are you trying to get the name "@_ZTIi" or "@__cxa_throw"?
Ciao,
Duncan.
2009 Mar 26
0
[LLVMdev] how to get the InvodInst 's Operand Name?
Hi zhangzw,
>> invoke void @__cxa_throw(i8* %7, i8* bitcast
>> (%struct.__fundamental_type_info_pseudo* @_ZTIi to i8*), void (i8*)*
>> null)
>> noreturn to label %invcont unwind label %lpad
>
> >>are you trying to get the name "@_ZTIi" or "@__cxa_throw"?
>
> yes! i want get the name @_ZTi or @__cxa_throw,
> the latter
2010 Mar 31
2
[LLVMdev] CFG entry and exit blocks
Hi,
I'm confused about the entry and exit blocks of an LLVM CFG. I
understand that every CFG has one and only one entry block, and this
is confirmed by the existence of the getEntryBlock function in the
Function class.
But what about exit (a.k.a. return) blocks? At first I assumed that
LLVM CFGs have one and only one exit block, too, but the following
code is a counter-example:
2010 Dec 02
2
[LLVMdev] Alternative exception handling proposal
Hi John,
>> Inlining
>> --------
>>
>> Many a plausible seeming exception handling scheme has fallen by the way-side
>> because it interacts poorly with inlining.
>>
>> Here is how inlining would work with this scheme. It's pretty close to how
>> it works right now. Suppose you have
>>
>> invoke void @foo()
>>
2010 Dec 01
0
[LLVMdev] Alternative exception handling proposal
On Dec 1, 2010, at 1:37 PM, Duncan Sands wrote:
> Inlining
> --------
>
> Many a plausible seeming exception handling scheme has fallen by the way-side
> because it interacts poorly with inlining.
>
> Here is how inlining would work with this scheme. It's pretty close to how
> it works right now. Suppose you have
>
> invoke void @foo()
> to
2010 Dec 02
3
[LLVMdev] Alternative exception handling proposal
Hi Bill,
> This is similar to my first proposal.
yup, I still consider your first proposal to have been basically sound.
But it also suffers from a major problem,
> which stopped that proposal dead in its tracks. Namely, you have information in
> one place which needs to be shared in two different, but possibly disjoint,
> places: the type, filters, and personality information. In
2010 Dec 01
0
[LLVMdev] Alternative exception handling proposal
On Dec 1, 2010, at 1:37 PM, Duncan Sands wrote:
> Executive summary
> -----------------
>
> Remove the personality and list of catches out of eh.selector and stick them
> directly on invoke instructions.
>
> The invoke instruction
> ----------------------
>
> The invoke instruction is modified by adding extra catch info to it:
>
> <result> = invoke
2010 Dec 02
0
[LLVMdev] Alternative exception handling proposal
On Dec 2, 2010, at 2:21 AM, Duncan Sands wrote:
> Hi Bill,
>
>> This is similar to my first proposal.
>
> yup, I still consider your first proposal to have been basically sound.
>
> But it also suffers from a major problem,
>> which stopped that proposal dead in its tracks. Namely, you have information in
>> one place which needs to be shared in two