llvm dev - Nov 2013 - [LLVMdev] conditional flow resulting in "Instruction does not dominate all uses!"

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

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>

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
]
>   ...
>
> 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. : )
It does. Do we produce an error/assert in this case?

Cheers,
Rafael