[LLVMdev] conditional flow resulting in "Instruction does not dominate all uses!"

[Henrique Santos]

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.

H.


On Sun, Nov 3, 2013 at 4:21 AM, edA-qa mort-ora-y <eda-qa at disemia.com>wrote:

> I've having a bit of a problem generating output that doesn't result in
> the "Instruction does not dominate all uses!". 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 `result`. That results in the error. However, based on
> the switching value `return_path` there is no way we can arrive at
> `next_step` unless result has actually been set. Is there some way I can
> tell LLVM this? Somehow just say "trust me", on the understanding that
> it would be totally undefined if we arrive at `next_step` without result
> being set?
>
> I know one generic approach, which I've started implementing, but I'm
> not sure it is a good solution. Instead of using results directly I
> always store in a local variable:
>
>         result = alloca result_type
>         tmp = invoke func to store_block unwind landing
>
> store_block:
>         store tmp, result
>         br defer_block
>
> ...
>
> next_step:
>         val = load result
>
> Here result would just be undefined if we arrive at `next_step` without
> having gone through `store_block`. It works, but my guess is that I'm
> hiding some valuable information from the optimizers.
>
>
> --
> 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/20131103/3b52d325/attachment.html>