Displaying 7 results from an estimated 7 matches for "defer_block".
2013 Nov 04
2
[LLVMdev] conditional flow resulting in "Instruction does not dominate all uses!"
...voke instruction and add the null value it's
> not.
> Won't that work?
>
Note that the return value of an invoke is defined on the *edge* of
the successful return. So you cannot have a path to a use that goes
through the exception instead. In your example you have:
landing -> defer_block -> next_step.
This Is a static property, so this code in invalid even if dynamically
this path is never taken.
Cheers,
Rafael
2013 Nov 04
0
[LLVMdev] conditional flow resulting in "Instruction does not dominate all uses!"
Well, what I had in mind was actually something like the following:
entry:
result0 = invoke func0 to defer_block unwind landing0
landing0:
landingpad
result1 = invoke func1 to defer_block unwind landing1
landing1:
landingpad
br defer_block
defer_block:
result = phi [ result0, entry ], [ result1, landing0 ], [ null, landing1 ]
...
This doesn't have landing pads with multiple predecessors li...
2013 Nov 04
2
[LLVMdev] conditional flow resulting in "Instruction does not dominate all uses!"
On 4 November 2013 08:19, Henrique Santos
<henrique.nazare.santos at gmail.com> wrote:
> Well, what I had in mind was actually something like the following:
>
> entry:
> result0 = invoke func0 to defer_block unwind landing0
>
> landing0:
> landingpad
> result1 = invoke func1 to defer_block unwind landing1
>
> landing1:
> landingpad
> br defer_block
>
> defer_block:
> result = phi [ result0, entry ], [ result1, landing0 ], [ null, landing1 ]
> ...
>
>...
2013 Nov 03
1
[LLVMdev] conditional flow resulting in "Instruction does not dominate all uses!"
...t;. In my code it relates to
exception handling and how I generate the blocks. I understand exactly
why I get the message, but I'm unsure of how I can structure things to
avoid the problem.
In a rough pseudo-code, my blocks look like this:
entry:
store 0, return_path
result = invoke func to defer_block unwind landing
landing:
landingpad
store 1, return_path
br defer_block
defer_block:
stuff
switch return_path, next_step [
0, next_step
1, rethrow
]
next_step:
val = load result ; error here
Structually the `next_step` has multiple preceding blocks, one of which
doesnt' define `...
2013 Nov 04
0
[LLVMdev] conditional flow resulting in "Instruction does not dominate all uses!"
...índola <rafael.espindola at gmail.com
> wrote:
> On 4 November 2013 08:19, Henrique Santos
> <henrique.nazare.santos at gmail.com> wrote:
> > Well, what I had in mind was actually something like the following:
> >
> > entry:
> > result0 = invoke func0 to defer_block unwind landing0
> >
> > landing0:
> > landingpad
> > result1 = invoke func1 to defer_block unwind landing1
> >
> > landing1:
> > landingpad
> > br defer_block
> >
> > defer_block:
> > result = phi [ result0, entry ], [ resu...
2013 Nov 04
3
[LLVMdev] conditional flow resulting in "Instruction does not dominate all uses!"
On 03/11/13 12:16, Henrique Santos wrote:
> You could try placing a phi node at "defer_block" with incoming value
> "result"
> when the incoming block is "entry", and do the same for "null" and
> "landing".
> Then, instead of loading "result", you load the value given by the newly
> created phi. That seems like the easie...
2013 Nov 04
0
[LLVMdev] conditional flow resulting in "Instruction does not dominate all uses!"
...the
incoming value if it's an invoke instruction and add the null value it's
not.
Won't that work?
On Mon, Nov 4, 2013 at 2:22 AM, edA-qa mort-ora-y <eda-qa at disemia.com>wrote:
> On 03/11/13 12:16, Henrique Santos wrote:
> > You could try placing a phi node at "defer_block" with incoming value
> > "result"
> > when the incoming block is "entry", and do the same for "null" and
> > "landing".
> > Then, instead of loading "result", you load the value given by the newly
> > created phi....