[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