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

Henrique Santos henrique.nazare.santos at gmail.com
Mon Nov 4 02:31:47 PST 2013


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>


More information about the llvm-dev mailing list