* [tree-ssa vs lno] who is right? @ 2004-03-26 5:32 Dale Johannesen 2004-03-26 6:34 ` Diego Novillo 2004-03-26 18:51 ` Zdenek Dvorak 0 siblings, 2 replies; 17+ messages in thread From: Dale Johannesen @ 2004-03-26 5:32 UTC (permalink / raw) To: gcc@gcc.gnu.org list; +Cc: Dale Johannesen When the LNO branch copies a loop, it attempts to fix up the phi nodes with an algorithm that assumes there is only one phi per block per variable. That is, it won't see code like this: ;; basic block 19, loop depth 0, count 0 ;; prev block 9, next block 20 ;; pred: 10 [100.0%] (fallthru) ;; succ: 28 [50.0%] (true,exec) 29 [50.0%] (false,exec) # maxmin_Result_140 = PHI <1(10)>; # maxmin_Result_142 = PHI <2(10)>; # lsm_tmp.19_144 = PHI <lsm_tmp.19_84(10)>; <L28>:; if (m__10 == 0) goto <L26>; else goto <L27>; Is that suppose to be a valid assumption? The dup is created by copyrename, and I see no code there that's intended to stop dups from being created (on the contrary, but surely it's unusual for the live ranges to overlap). ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [tree-ssa vs lno] who is right? 2004-03-26 5:32 [tree-ssa vs lno] who is right? Dale Johannesen @ 2004-03-26 6:34 ` Diego Novillo 2004-03-26 6:35 ` Dale Johannesen ` (2 more replies) 2004-03-26 18:51 ` Zdenek Dvorak 1 sibling, 3 replies; 17+ messages in thread From: Diego Novillo @ 2004-03-26 6:34 UTC (permalink / raw) To: Dale Johannesen; +Cc: gcc@gcc.gnu.org list On Thu, 2004-03-25 at 20:29, Dale Johannesen wrote: > ;; basic block 19, loop depth 0, count 0 > ;; prev block 9, next block 20 > ;; pred: 10 [100.0%] (fallthru) > ;; succ: 28 [50.0%] (true,exec) 29 [50.0%] (false,exec) > # maxmin_Result_140 = PHI <1(10)>; > # maxmin_Result_142 = PHI <2(10)>; > # lsm_tmp.19_144 = PHI <lsm_tmp.19_84(10)>; > <L28>:; > if (m__10 == 0) goto <L26>; else goto <L27>; > > Is that suppose to be a valid assumption? The dup is created by > copyrename, and > I see no code there that's intended to stop dups from being created (on > the > contrary, but surely it's unusual for the live ranges to overlap). > Are maxmin_Result the same variable? Use -uid to find out. If they both have the same UID, they're the same and that's a bug. There should only be a single PHI node per variable in a basic block. Diego. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [tree-ssa vs lno] who is right? 2004-03-26 6:34 ` Diego Novillo @ 2004-03-26 6:35 ` Dale Johannesen 2004-03-26 7:08 ` Diego Novillo 2004-03-26 7:27 ` Andrew Pinski 2004-03-26 16:21 ` Andrew MacLeod 2004-03-26 16:44 ` law 2 siblings, 2 replies; 17+ messages in thread From: Dale Johannesen @ 2004-03-26 6:35 UTC (permalink / raw) To: Diego Novillo; +Cc: gcc@gcc.gnu.org list, Dale Johannesen On Mar 25, 2004, at 5:32 PM, Diego Novillo wrote: > On Thu, 2004-03-25 at 20:29, Dale Johannesen wrote: > >> ;; basic block 19, loop depth 0, count 0 >> ;; prev block 9, next block 20 >> ;; pred: 10 [100.0%] (fallthru) >> ;; succ: 28 [50.0%] (true,exec) 29 [50.0%] (false,exec) >> # maxmin_Result_140 = PHI <1(10)>; >> # maxmin_Result_142 = PHI <2(10)>; >> # lsm_tmp.19_144 = PHI <lsm_tmp.19_84(10)>; >> <L28>:; >> if (m__10 == 0) goto <L26>; else goto <L27>; >> >> Is that suppose to be a valid assumption? The dup is created by >> copyrename, and >> I see no code there that's intended to stop dups from being created >> (on >> the >> contrary, but surely it's unusual for the live ranges to overlap). Thanks. > Are maxmin_Result the same variable? Use -uid to find out. How? Doesn't like that as a command line option... > If they both have the same UID, they're the same and that's a bug. > There should > only be a single PHI node per variable in a basic block. They are the same VAR_DECL (pointed to from different SSA_NAMEs). Is it one of the UIDs in there that matters, or the one in the PHI? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [tree-ssa vs lno] who is right? 2004-03-26 6:35 ` Dale Johannesen @ 2004-03-26 7:08 ` Diego Novillo 2004-03-26 7:27 ` Andrew Pinski 1 sibling, 0 replies; 17+ messages in thread From: Diego Novillo @ 2004-03-26 7:08 UTC (permalink / raw) To: Dale Johannesen; +Cc: gcc@gcc.gnu.org list On Thu, 2004-03-25 at 20:58, Dale Johannesen wrote: > > Are maxmin_Result the same variable? Use -uid to find out. > > How? Doesn't like that as a command line option... > Sorry. I meant -fdump-tree-... I usually just say, -fdump-tree-all-vops-uid (to get both virtual operands and UIDs dumped). > They are the same VAR_DECL (pointed to from different SSA_NAMEs). > Is it one of the UIDs in there that matters, or the one in the PHI? > If the UIDs are different, then they are different VAR_DECLs, but if you've already tested that they are the same VAR_DECL pointer, then I guess we have a bug. Mind opening a PR? Diego. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [tree-ssa vs lno] who is right? 2004-03-26 6:35 ` Dale Johannesen 2004-03-26 7:08 ` Diego Novillo @ 2004-03-26 7:27 ` Andrew Pinski 1 sibling, 0 replies; 17+ messages in thread From: Andrew Pinski @ 2004-03-26 7:27 UTC (permalink / raw) To: Dale Johannesen; +Cc: gcc@gcc.gnu.org list, Andrew Pinski, Diego Novillo On Mar 25, 2004, at 17:58, Dale Johannesen wrote: >> Are maxmin_Result the same variable? Use -uid to find out. > > How? Doesn't like that as a command line option... -fdump-tree-uid Thanks, Andrew Pinski ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [tree-ssa vs lno] who is right? 2004-03-26 6:34 ` Diego Novillo 2004-03-26 6:35 ` Dale Johannesen @ 2004-03-26 16:21 ` Andrew MacLeod 2004-03-26 16:31 ` Diego Novillo 2004-03-26 16:44 ` law 2 siblings, 1 reply; 17+ messages in thread From: Andrew MacLeod @ 2004-03-26 16:21 UTC (permalink / raw) To: Diego Novillo; +Cc: Dale Johannesen, gcc mailing list On Thu, 2004-03-25 at 20:32, Diego Novillo wrote: > On Thu, 2004-03-25 at 20:29, Dale Johannesen wrote: > > > ;; basic block 19, loop depth 0, count 0 > > ;; prev block 9, next block 20 > > ;; pred: 10 [100.0%] (fallthru) > > ;; succ: 28 [50.0%] (true,exec) 29 [50.0%] (false,exec) > > # maxmin_Result_140 = PHI <1(10)>; > > # maxmin_Result_142 = PHI <2(10)>; > > # lsm_tmp.19_144 = PHI <lsm_tmp.19_84(10)>; > > <L28>:; > > if (m__10 == 0) goto <L26>; else goto <L27>; > > > > Is that suppose to be a valid assumption? The dup is created by > > copyrename, and > > I see no code there that's intended to stop dups from being created (on > > the > > contrary, but surely it's unusual for the live ranges to overlap). > > > Are maxmin_Result the same variable? Use -uid to find out. If they > both have the same UID, they're the same and that's a bug. There should > only be a single PHI node per variable in a basic block. I dont see why we have to have that restriction... maxmin_Result_140 and maxmin_Result_142 should be treated as two completely different variables. Why should we say its a bug to allow that to happen? If the live range of SSA_NAMEs can overlap, why can't they overlap here? What are the arguments for dissallowing it? Andrew ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [tree-ssa vs lno] who is right? 2004-03-26 16:21 ` Andrew MacLeod @ 2004-03-26 16:31 ` Diego Novillo 2004-03-26 16:40 ` Andrew MacLeod 0 siblings, 1 reply; 17+ messages in thread From: Diego Novillo @ 2004-03-26 16:31 UTC (permalink / raw) To: Andrew Macleod; +Cc: Dale Johannesen, gcc mailing list On Fri, 2004-03-26 at 07:42, Andrew MacLeod wrote: > If the live range of SSA_NAMEs can overlap, why can't they overlap here? > What are the arguments for dissallowing it? > You're absolutely right. I don't know what I was thinking. Sorry Dale. Disregard what I said. I wasn't paying attention. Is this leading you to a codegen bug or a compiler abort? Diego. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [tree-ssa vs lno] who is right? 2004-03-26 16:31 ` Diego Novillo @ 2004-03-26 16:40 ` Andrew MacLeod 2004-03-26 17:48 ` law 0 siblings, 1 reply; 17+ messages in thread From: Andrew MacLeod @ 2004-03-26 16:40 UTC (permalink / raw) To: Diego Novillo; +Cc: Dale Johannesen, gcc mailing list On Fri, 2004-03-26 at 07:52, Diego Novillo wrote: > On Fri, 2004-03-26 at 07:42, Andrew MacLeod wrote: > > > If the live range of SSA_NAMEs can overlap, why can't they overlap here? > > What are the arguments for dissallowing it? > > > You're absolutely right. I don't know what I was thinking. > > Sorry Dale. Disregard what I said. I wasn't paying attention. Is this > leading you to a codegen bug or a compiler abort? > That said, this case turns out to be not productive, so send me an example and I'll see if its something preventable, or just a casualty of optimization (which I suspect is the case). I have some minor changes to copyrename in the queue, but I doubt it will affect this. Since there is a constant in the arguments of the PHI, it must have been renamed due to a copy between a temp and maxmin_Result elsewhere in the program. The hope was that we'd be able to get rid of the copy. Looks like not, unless one or more of the PHIs can be optimized away. :-) Andrew ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [tree-ssa vs lno] who is right? 2004-03-26 16:40 ` Andrew MacLeod @ 2004-03-26 17:48 ` law 2004-03-26 18:08 ` Andrew MacLeod 0 siblings, 1 reply; 17+ messages in thread From: law @ 2004-03-26 17:48 UTC (permalink / raw) To: Andrew MacLeod; +Cc: Diego Novillo, Dale Johannesen, gcc mailing list In message <1080308082.12528.27.camel@p4>, Andrew MacLeod writes: >I have some minor changes to copyrename in the queue, but I doubt it >will affect this. Since there is a constant in the arguments of the PHI, >it must have been renamed due to a copy between a temp and maxmin_Result >elsewhere in the program. The hope was that we'd be able to get rid of >the copy. Looks like not, unless one or more of the PHIs can be >optimized away. :-) I'd expect DOM to propagate the constants so that there were no uses of maxmin_Result_140, maxmin_Result_142, then I'd expect DCE to zap the useless PHIs. Alternatively Zdenek's block trivial PHI removal code may zap them. But again, I think step #1 is to figure out how we got them in the first place. jeff ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [tree-ssa vs lno] who is right? 2004-03-26 17:48 ` law @ 2004-03-26 18:08 ` Andrew MacLeod 2004-03-26 18:10 ` law 0 siblings, 1 reply; 17+ messages in thread From: Andrew MacLeod @ 2004-03-26 18:08 UTC (permalink / raw) To: Jeff Law; +Cc: Diego Novillo, Dale Johannesen, gcc mailing list On Fri, 2004-03-26 at 10:30, law@redhat.com wrote: > In message <1080308082.12528.27.camel@p4>, Andrew MacLeod writes: > >I have some minor changes to copyrename in the queue, but I doubt it > >will affect this. Since there is a constant in the arguments of the PHI, > >it must have been renamed due to a copy between a temp and maxmin_Result > >elsewhere in the program. The hope was that we'd be able to get rid of > >the copy. Looks like not, unless one or more of the PHIs can be > >optimized away. :-) > I'd expect DOM to propagate the constants so that there were no uses > of maxmin_Result_140, maxmin_Result_142, then I'd expect DCE to zap the > useless PHIs. > > Alternatively Zdenek's block trivial PHI removal code may zap them. > > But again, I think step #1 is to figure out how we got them in the first > place. > jeff > It would be pretty easy, something like: maxmin_Result_140 = PHI <1(10)>; T.55_142 = PHI <2(10)>; <...> maxmin_Result_133 = T.55_142 could result in the 2 PHI nodes since we'd rename T.55_142 to maxmin_Result_133 in hopes of getting rid of the copy. It could also happen if T.55_142 is later used as a PHI argument to a maxmin_Result PHI result. Andrew ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [tree-ssa vs lno] who is right? 2004-03-26 18:08 ` Andrew MacLeod @ 2004-03-26 18:10 ` law 2004-03-26 18:49 ` Dale Johannesen 0 siblings, 1 reply; 17+ messages in thread From: law @ 2004-03-26 18:10 UTC (permalink / raw) To: Andrew MacLeod; +Cc: Diego Novillo, Dale Johannesen, gcc mailing list In message <1080315577.12834.102.camel@p4>, Andrew MacLeod writes: >On Fri, 2004-03-26 at 10:30, law@redhat.com wrote: >> In message <1080308082.12528.27.camel@p4>, Andrew MacLeod writes: >> >I have some minor changes to copyrename in the queue, but I doubt it >> >will affect this. Since there is a constant in the arguments of the PHI, >> >it must have been renamed due to a copy between a temp and maxmin_Result >> >elsewhere in the program. The hope was that we'd be able to get rid of >> >the copy. Looks like not, unless one or more of the PHIs can be >> >optimized away. :-) >> I'd expect DOM to propagate the constants so that there were no uses >> of maxmin_Result_140, maxmin_Result_142, then I'd expect DCE to zap the >> useless PHIs. >> >> Alternatively Zdenek's block trivial PHI removal code may zap them. >> >> But again, I think step #1 is to figure out how we got them in the first >> place. >> jeff >> > >It would be pretty easy, something like: > >maxmin_Result_140 = PHI <1(10)>; >T.55_142 = PHI <2(10)>; ><...> >maxmin_Result_133 = T.55_142 > >could result in the 2 PHI nodes since we'd rename T.55_142 to >maxmin_Result_133 in hopes of getting rid of the copy. > >It could also happen if T.55_142 is later used as a PHI argument to a >maxmin_Result PHI result. Ah yes. Seems quite reasonable. jeff ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [tree-ssa vs lno] who is right? 2004-03-26 18:10 ` law @ 2004-03-26 18:49 ` Dale Johannesen 0 siblings, 0 replies; 17+ messages in thread From: Dale Johannesen @ 2004-03-26 18:49 UTC (permalink / raw) To: law; +Cc: Diego Novillo, Dale Johannesen, Andrew MacLeod, gcc mailing list On Mar 26, 2004, at 8:06 AM, law@redhat.com wrote: > In message <1080315577.12834.102.camel@p4>, Andrew MacLeod writes: >> On Fri, 2004-03-26 at 10:30, law@redhat.com wrote: >>> In message <1080308082.12528.27.camel@p4>, Andrew MacLeod writes: >>> But again, I think step #1 is to figure out how we got them in the >>> first >>> place. >>> jeff >>> >> >> It would be pretty easy, something like: >> >> maxmin_Result_140 = PHI <1(10)>; >> T.55_142 = PHI <2(10)>; >> <...> >> maxmin_Result_133 = T.55_142 >> >> could result in the 2 PHI nodes since we'd rename T.55_142 to >> maxmin_Result_133 in hopes of getting rid of the copy. >> >> It could also happen if T.55_142 is later used as a PHI argument to a >> maxmin_Result PHI result. > Ah yes. Seems quite reasonable. Well, at least this wasn't a trivial question...thanks to all of you. So the consensus is that copyrename's behavior is valid and reasonable, and the only thing wrong here is the LNO branch's algorithm that assumes otherwise. Right? I'll go fix that. (The testcase is from sixtrack in SPEC; it's small, though, I may be able to come up with something not copyrighted.) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [tree-ssa vs lno] who is right? 2004-03-26 6:34 ` Diego Novillo 2004-03-26 6:35 ` Dale Johannesen 2004-03-26 16:21 ` Andrew MacLeod @ 2004-03-26 16:44 ` law 2004-03-26 17:42 ` Diego Novillo 2 siblings, 1 reply; 17+ messages in thread From: law @ 2004-03-26 16:44 UTC (permalink / raw) To: Diego Novillo; +Cc: Dale Johannesen, gcc@gcc.gnu.org list In message <1080264779.4600.25.camel@localhost.localdomain>, Diego Novillo writ es: >On Thu, 2004-03-25 at 20:29, Dale Johannesen wrote: > >> ;; basic block 19, loop depth 0, count 0 >> ;; prev block 9, next block 20 >> ;; pred: 10 [100.0%] (fallthru) >> ;; succ: 28 [50.0%] (true,exec) 29 [50.0%] (false,exec) >> # maxmin_Result_140 = PHI <1(10)>; >> # maxmin_Result_142 = PHI <2(10)>; >> # lsm_tmp.19_144 = PHI <lsm_tmp.19_84(10)>; >> <L28>:; >> if (m__10 == 0) goto <L26>; else goto <L27>; >> >> Is that suppose to be a valid assumption? The dup is created by >> copyrename, and >> I see no code there that's intended to stop dups from being created (on >> the >> contrary, but surely it's unusual for the live ranges to overlap). >> >Are maxmin_Result the same variable? Use -uid to find out. If they >both have the same UID, they're the same and that's a bug. There should >only be a single PHI node per variable in a basic block. Why would that be a bug? It just means that we have overlapping lifetimes for the two objects. It's certainly a little odd, but I wouldn't go straight to classifying it as a bug. Instead I would suggest looking into the first place where these two PHIs appeared and figure out why it happened. It could be a bug or it could be normal behavior. jeff ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [tree-ssa vs lno] who is right? 2004-03-26 16:44 ` law @ 2004-03-26 17:42 ` Diego Novillo 0 siblings, 0 replies; 17+ messages in thread From: Diego Novillo @ 2004-03-26 17:42 UTC (permalink / raw) To: Jeff Law; +Cc: Dale Johannesen, gcc@gcc.gnu.org list On Fri, 2004-03-26 at 10:28, law@redhat.com wrote: > Why would that be a bug? It just means that we have overlapping lifetimes > for the two objects. > Yeah, I was smoking FUD chains again. Diego. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [tree-ssa vs lno] who is right? 2004-03-26 5:32 [tree-ssa vs lno] who is right? Dale Johannesen 2004-03-26 6:34 ` Diego Novillo @ 2004-03-26 18:51 ` Zdenek Dvorak 2004-03-26 20:15 ` Dale Johannesen 1 sibling, 1 reply; 17+ messages in thread From: Zdenek Dvorak @ 2004-03-26 18:51 UTC (permalink / raw) To: Dale Johannesen; +Cc: gcc@gcc.gnu.org list Hello, > When the LNO branch copies a loop, it attempts to fix up the phi nodes > with > an algorithm that assumes there is only one phi per block per variable. > That is, it > won't see code like this: where do we assume this (i.e. what do you mean by "copying a loop")? While this certainly is unlikely to happen, there probably is nothing that would prevent it. Zdenek > ;; basic block 19, loop depth 0, count 0 > ;; prev block 9, next block 20 > ;; pred: 10 [100.0%] (fallthru) > ;; succ: 28 [50.0%] (true,exec) 29 [50.0%] (false,exec) > # maxmin_Result_140 = PHI <1(10)>; > # maxmin_Result_142 = PHI <2(10)>; > # lsm_tmp.19_144 = PHI <lsm_tmp.19_84(10)>; > <L28>:; > if (m__10 == 0) goto <L26>; else goto <L27>; > > Is that suppose to be a valid assumption? The dup is created by > copyrename, and > I see no code there that's intended to stop dups from being created (on > the > contrary, but surely it's unusual for the live ranges to overlap). > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [tree-ssa vs lno] who is right? 2004-03-26 18:51 ` Zdenek Dvorak @ 2004-03-26 20:15 ` Dale Johannesen 2004-03-26 21:09 ` Devang Patel 0 siblings, 1 reply; 17+ messages in thread From: Dale Johannesen @ 2004-03-26 20:15 UTC (permalink / raw) To: Zdenek Dvorak; +Cc: gcc@gcc.gnu.org list, Dale Johannesen On Mar 26, 2004, at 10:10 AM, Zdenek Dvorak wrote: > Hello, > >> When the LNO branch copies a loop, it attempts to fix up the phi nodes >> with >> an algorithm that assumes there is only one phi per block per >> variable. >> That is, it >> won't see code like this: > > (i.e. what do you mean by "copying a loop")? tree_duplicate_loop_to_header_edge (called from unswitching in the failing case) > where do we assume this lv_adjust_loop_header_phi . The assumption is explicit: /* There can not be second phi node for the same variable. Get out of the for loop that walks phi nodes of 'first'. */ There isn't any way to find the right phi at that point AFAICT, so I'm thinking along the lines of making sure the phi lists are in the same order when doing the loop duplication earlier (they aren't now). > While this certainly is unlikely to happen, there probably is nothing > that would prevent it. > Zdenek > >> ;; basic block 19, loop depth 0, count 0 >> ;; prev block 9, next block 20 >> ;; pred: 10 [100.0%] (fallthru) >> ;; succ: 28 [50.0%] (true,exec) 29 [50.0%] (false,exec) >> # maxmin_Result_140 = PHI <1(10)>; >> # maxmin_Result_142 = PHI <2(10)>; >> # lsm_tmp.19_144 = PHI <lsm_tmp.19_84(10)>; >> <L28>:; >> if (m__10 == 0) goto <L26>; else goto <L27>; >> >> Is that suppose to be a valid assumption? The dup is created by >> copyrename, and >> I see no code there that's intended to stop dups from being created >> (on >> the >> contrary, but surely it's unusual for the live ranges to overlap). >> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [tree-ssa vs lno] who is right? 2004-03-26 20:15 ` Dale Johannesen @ 2004-03-26 21:09 ` Devang Patel 0 siblings, 0 replies; 17+ messages in thread From: Devang Patel @ 2004-03-26 21:09 UTC (permalink / raw) To: Dale Johannesen; +Cc: Zdenek Dvorak, gcc@gcc.gnu.org list On Mar 26, 2004, at 10:22 AM, Dale Johannesen wrote: > > On Mar 26, 2004, at 10:10 AM, Zdenek Dvorak wrote: > >> Hello, >> >>> When the LNO branch copies a loop, it attempts to fix up the phi >>> nodes >>> with >>> an algorithm that assumes there is only one phi per block per >>> variable. >>> That is, it >>> won't see code like this: >> >> (i.e. what do you mean by "copying a loop")? > > tree_duplicate_loop_to_header_edge (called from unswitching in the > failing case) I saw this happening couple of days ago at this point in tree_duplicate_loop... /* Add phi nodes for definitions to exit_block (we could find out which of them are really used outside of the loop and don't emit the phi nodes for the remaining ones; for this we would however need to know immediate uses). */ for (arg = usable_outside; arg; arg = TREE_CHAIN (arg)) { def = TREE_VALUE (arg); phi = create_phi_node (def, exit_block); for (ae = exit_block->pred; ae; ae = ae->pred_next) add_phi_arg (&phi, def, ae); } >> where do we assume this > > lv_adjust_loop_header_phi . The assumption is explicit: > > /* There can not be second phi node for the same > variable. > Get out of the for loop that walks phi nodes > of 'first'. > */ Yes, that's what my understanding was (until this thread). I'm glad I note down my assumptions. > There isn't any way to find the right phi at that point AFAICT, That's what I found at that time... here is what I am trying to do in lv_adjust_loop_header_phi /* Adjust phi nodes for 'first' basic block. 'second' basic block is a copy of 'first'. Both of them are dominated by 'new_head' basic block. When 'new_head' was created by [splitting] 'second's incoming edge it received phi arguments on the edge by split_edge(). Later, additional edge 'e' was created to connect 'new_head' and 'first'. Now this routnine adds phi args on this additional edge 'e' that new_head to second edge received as part of edge splitting. */ - Devang > so I'm thinking > along the lines of making sure the phi lists are in the same order > when doing > the loop duplication earlier (they aren't now). > >> While this certainly is unlikely to happen, there probably is nothing >> that would prevent it. > >> Zdenek >> >>> ;; basic block 19, loop depth 0, count 0 >>> ;; prev block 9, next block 20 >>> ;; pred: 10 [100.0%] (fallthru) >>> ;; succ: 28 [50.0%] (true,exec) 29 [50.0%] (false,exec) >>> # maxmin_Result_140 = PHI <1(10)>; >>> # maxmin_Result_142 = PHI <2(10)>; >>> # lsm_tmp.19_144 = PHI <lsm_tmp.19_84(10)>; >>> <L28>:; >>> if (m__10 == 0) goto <L26>; else goto <L27>; >>> >>> Is that suppose to be a valid assumption? The dup is created by >>> copyrename, and >>> I see no code there that's intended to stop dups from being created >>> (on >>> the >>> contrary, but surely it's unusual for the live ranges to overlap). >>> ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2004-03-26 18:46 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-03-26 5:32 [tree-ssa vs lno] who is right? Dale Johannesen 2004-03-26 6:34 ` Diego Novillo 2004-03-26 6:35 ` Dale Johannesen 2004-03-26 7:08 ` Diego Novillo 2004-03-26 7:27 ` Andrew Pinski 2004-03-26 16:21 ` Andrew MacLeod 2004-03-26 16:31 ` Diego Novillo 2004-03-26 16:40 ` Andrew MacLeod 2004-03-26 17:48 ` law 2004-03-26 18:08 ` Andrew MacLeod 2004-03-26 18:10 ` law 2004-03-26 18:49 ` Dale Johannesen 2004-03-26 16:44 ` law 2004-03-26 17:42 ` Diego Novillo 2004-03-26 18:51 ` Zdenek Dvorak 2004-03-26 20:15 ` Dale Johannesen 2004-03-26 21:09 ` Devang Patel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).