<div dir="ltr"><div>You could try placing a phi node at "defer_block" with incoming value "result" <br>when the incoming block is "entry", and do the same for "null" and "landing". <br>


Then, instead of loading "result", you load the value given by the newly <br>created phi. That seems like the easiest solution.<br><br></div>H.<div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Nov 3, 2013 at 4:21 AM, edA-qa mort-ora-y <span dir="ltr"><<a href="mailto:eda-qa@disemia.com" target="_blank">eda-qa@disemia.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've having a bit of a problem generating output that doesn't result in<br>
the "Instruction does not dominate all uses!". In my code it relates to<br>
exception handling and how I generate the blocks. I understand exactly<br>
why I get the message, but I'm unsure of how I can structure things to<br>
avoid the problem.<br>
<br>
In a rough pseudo-code, my blocks look like this:<br>
<br>
entry:<br>
        store 0, return_path<br>
        result = invoke func to defer_block unwind landing<br>
<br>
landing:<br>
        landingpad<br>
        store 1, return_path<br>
        br defer_block<br>
<br>
defer_block:<br>
        stuff<br>
        switch return_path, next_step [<br>
                0, next_step<br>
                1, rethrow<br>
        ]<br>
<br>
next_step:<br>
        val = load result  ; error here<br>
<br>
<br>
Structually the `next_step` has multiple preceding blocks, one of which<br>
doesnt' define `result`. That results in the error. However, based on<br>
the switching value `return_path` there is no way we can arrive at<br>
`next_step` unless result has actually been set. Is there some way I can<br>
tell LLVM this? Somehow just say "trust me", on the understanding that<br>
it would be totally undefined if we arrive at `next_step` without result<br>
being set?<br>
<br>
I know one generic approach, which I've started implementing, but I'm<br>
not sure it is a good solution. Instead of using results directly I<br>
always store in a local variable:<br>
<br>
        result = alloca result_type<br>
        tmp = invoke func to store_block unwind landing<br>
<br>
store_block:<br>
        store tmp, result<br>
        br defer_block<br>
<br>
...<br>
<br>
next_step:<br>
        val = load result<br>
<br>
Here result would just be undefined if we arrive at `next_step` without<br>
having gone through `store_block`. It works, but my guess is that I'm<br>
hiding some valuable information from the optimizers.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
edA-qa mort-ora-y<br>
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --<br>
Sign: Please digitally sign your emails.<br>
Encrypt: I'm also happy to receive encrypted mail.<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</font></span></blockquote></div><br></div></div>