llvm dev - Nov 2013 - [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 easiest solution.
I looked at doing this. It isn't easy however since the landingpad can
be shared by several invoke points (as does the defer/following blocks).
If I could figure out how to combine it together then the phi might make
sense.

I created the same situation in C++ and got clang to generate LLVM-IR.
It appears they are using local variables (alloca) for this situation.


-- 
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.

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?


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. That seems like the easiest solution.
>
> I looked at doing this. It isn't easy however since the landingpad can
> be shared by several invoke points (as does the defer/following blocks).
> If I could figure out how to combine it together then the phi might make
> sense.
>
> I created the same situation in C++ and got clang to generate LLVM-IR.
> It appears they are using local variables (alloca) for this situation.
>
>
> --
> edA-qa mort-ora-y
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> Sign: Please digitally sign your emails.
> Encrypt: I'm also happy to receive encrypted mail.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131104/fbb8c688/attachment.html>

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

On 04/11/13 11:31, Henrique Santos 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?
I never thought of that option. I could do post-processing and simply
add the missing predecessors to the PHI statement. I'd use undefined
instead of null however. I'm not sure if it is a simple thing to
experiment with however. My example was nice in clean, but in reality
that result value is used at some arbitrary place later in the code --
it isn't clear (from my compiler's viewpoint) where the values come
together in a phi. But the idea makes sense, so I'll see if I can use it
somehow.

The other option I've toyed with before was actually creating distinct
landing pad paths. I just duplicated all the deferred code, once into
the normal path, once into the exception path. I'm still too far away
from a version where I can test if this is helpful. It's certainly more
code, but the non-exception path and can be heavily optimized then.

Thanks.



-- 
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.