[LLVMdev] conditional flow resulting in "Instruction does not dominate all uses!"
Henrique Santos
henrique.nazare.santos at gmail.com
Mon Nov 4 08:19:57 PST 2013
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 like he said,
but I don't think that would make much difference.
The "defer block", however, is the target of multiple invokes.
I hope this makes sense. : )
H.
On Mon, Nov 4, 2013 at 1:54 PM, Rafael EspĂndola <rafael.espindola at gmail.com
> wrote:
> On 4 November 2013 02:31, Henrique Santos
> <henrique.nazare.santos at gmail.com> wrote:
> > But the incoming value from the landing pad will always be null, won't
> it?
> > If so, just iterate through the predecessors and add the terminator as
> the
> > incoming value if it's an invoke 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131104/c743f4bd/attachment.html>
More information about the llvm-dev
mailing list