[LLVMdev] Updating PHI for Instruction Domination?

[Ryan Taylor]

So my best bet is to try and work in reg2mem mode and then go back to
mem2reg?

I'm curious, it seems though when you split a block that the phis get
updated, right?

On Thu, Feb 2, 2012 at 5:05 PM, Eric Christopher <echristo at apple.com> wrote:

> Not that I'm aware of.
>
> -eric
>
> On Feb 2, 2012, at 3:47 PM, Ryan Taylor wrote:
>
> So essentially I'm adding a path inside of the loop. Is there a way to
> have llvm automatically create new IR and update the PHIs simply by adding
> a block like this and changing the DomTree?
>
> ---------- Forwarded message ----------
> From: Ryan Taylor <ryta1203 at gmail.com>
> Date: Thu, Feb 2, 2012 at 12:08 PM
> Subject: Updating PHI for Instruction Domination?
> To: llvmdev at cs.uiuc.edu
>
>
> So I have a loop with two blocks, a header (which points to return and
> latch) and a latch (which points to return and header). I have inserted a
> few new blocks, called H and F.
>
> Header now points to H and latch. Latch now points to F. H points to F. F
> points to Header and return.
>
> The PHI Nodes have been updated in Header accordingly, now coming from the
> preheader and F (instead of latch).
>
> My issue is this: The values in the PHI instruction in the Header for F
> are actually defined in Latch and so if you follow the path: Header->H->F,
> there becomes an issue with "Instruction does not dominate all uses" (since
> the Header PHI is getting values defined in Latch coming from F but never
> going to Latch) since they haven't been defined in that path.
>
> My question is: Is there some call where I can rearrange the basic blocks
> and call some functions/utils that solve this issue? Or do I have to
> manually solve this myself?
>
> Thanks again.
>
> _______________________________________________
> 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/20120202/dfb592e1/attachment.html>