[LLVMdev] Updating PHI for Instruction Domination?

[Ryan Taylor]

Andy,

 Thanks for the response. I fixed this, seems to be working fairly well so
far, I did have to manually iterate over phi nodes and modify each one
accordingly. The value problem was a mistake on my part, the new PHI node
instructions were the values. It would seem however that there should be
calls, once all the branching is done, that can automate over the new cfg
and determine the PHI nodes (blocks and values) needed and automatically
insert them.

Thanks everyone.

On Mon, Feb 6, 2012 at 2:23 PM, Andrew Trick <atrick at apple.com> wrote:

> You're creating a new path that doesn't include L. For all values defined
> in L and used outside of L, you need to determine the new reaching def.
> That's specific to your transformation and can't be automated. Once you do
> that, creating the phi in F is natural.
> -Andy
>
> On Feb 6, 2012, at 11:51 AM, Ryan Taylor <ryta1203 at gmail.com> wrote:
>
> I guess not since Value is a superclass of Instruction.
>
> On Mon, Feb 6, 2012 at 10:36 AM, Ryan Taylor <ryta1203 at gmail.com> wrote:
>
>>
>>
>> ---------- Forwarded message ----------
>> From: Ryan Taylor <ryta1203 at gmail.com>
>> Date: Mon, Feb 6, 2012 at 10:36 AM
>> Subject: Re: [LLVMdev] Updating PHI for Instruction Domination?
>> To: Eric Christopher <echristo at apple.com>
>>
>>
>> Since I'm not sure which instructions I might want to replicate, would it
>> be possible to cast the Value from "PHINode::getIncomingValue" to
>> "Instruction" and then copy that and cast it back?
>>
>>
>> On Sun, Feb 5, 2012 at 8:49 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:
>>
>>>
>>>
>>> On Sun, Feb 5, 2012 at 5:15 PM, Eric Christopher <echristo at apple.com>wrote:
>>>
>>>>
>>>> On Feb 2, 2012, at 5:13 PM, Ryan Taylor wrote:
>>>>
>>>> > So my best bet is to try and work in reg2mem mode and then go back to
>>>> mem2reg?
>>>> >
>>>>
>>>> I wouldn't. That sounds painful.
>>>>
>>>> > I'm curious, it seems though when you split a block that the phis get
>>>> updated, right?
>>>>
>>>> Sure. There's code in splitBasicBlock to do this. It should just take a
>>>> little bit of work to get what you want done.
>>>>
>>>> -eric
>>>>
>>>
>>> Yes, the first DOES sound painful (I want to avoid it) and the second is
>>> not an option. I'm adding a second path in a loop.
>>>
>>> The old path: BB1->BB2/BB3, BB2->BB1/BB3, BB3->n/a
>>>
>>> The new path: BB1->H/BB2, BB2->F/K, H->F, K->F,  F->BB1/G, G->BB3
>>>
>>> There are PHI nodes in BB1 that come in from BB2 for values defined in
>>> BB2. With the new possible path: BB1->H->F, BB2. Without adding new PHIs or
>>> Values, there exists a dominance instruction issue. So I want to create
>>> PHIs in F for each value in BB2 that is used in BB1. The update the PHI
>>> Values in BB1 (that used to come from BB2) to the new values in F (which
>>> are getting values from BB2/H).
>>>
>>> The problem is that there is no way to copy the value from BB2, since
>>> there exists no Value constructor!?
>>>
>>> This seems like a pretty large limitation anytime anyone wants to add a
>>> branch inside a loop? Is there an easier way to get what I want that I'm
>>> missing?
>>>
>>
>>
>>
> _______________________________________________
> 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/20120206/57ad44ce/attachment.html>