* Puzzle about CFG on rtl during delay slot schedule @ 2010-04-02 9:29 Amker.Cheng 2010-04-02 9:43 ` Steven Bosscher 0 siblings, 1 reply; 7+ messages in thread From: Amker.Cheng @ 2010-04-02 9:29 UTC (permalink / raw) To: gcc Hi : I'm wondering whether cfg is maintained properly during delay slot scheduling, Because when compiling libgcc/_divsc3.o, rtl dump in libgcc2.c.198r.mach has following lines: no bb for insn with uid = 293. deleting insn with uid = 690. deleting insn with uid = 904. ...... (note 298 905 303 [bb 25] NOTE_INSN_BASIC_BLOCK) (note 303 298 304 [bb 26] NOTE_INSN_BASIC_BLOCK) -------------------------------------cut here after that pass, bb 25 still has il.rtl->head_ == insn_uid_690, which has already deleted. Seems the bb's head_/tail_ are not handled properly. I traced cc1 and found it deleted insn_690 by function remove_insn, It seems that the end the function takes BB_HEAD/BB_END into consider, But the BLOCK_FOR_INSN(insn_690) is null, which results in the problem. BTW, the version working on is gcc-4.4.1, mips target. So, any tips? Thanks very much. -- Best Regards. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Puzzle about CFG on rtl during delay slot schedule 2010-04-02 9:29 Puzzle about CFG on rtl during delay slot schedule Amker.Cheng @ 2010-04-02 9:43 ` Steven Bosscher [not found] ` <v2ue8b251c81004020340tf3fb7416s12756e0a7560c102@mail.gmail.com> 0 siblings, 1 reply; 7+ messages in thread From: Steven Bosscher @ 2010-04-02 9:43 UTC (permalink / raw) To: Amker.Cheng; +Cc: gcc On Fri, Apr 2, 2010 at 11:28 AM, Amker.Cheng <amker.cheng@gmail.com> wrote: > Hi : > I'm wondering whether cfg is maintained properly during delay slot > scheduling, The CFG is not maintained during delay slot scheduling. This is, in fact, a very old and well-known problem. Look for any e-mail on this list that mentions reorg.c :-) Ciao! Steven ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <v2ue8b251c81004020340tf3fb7416s12756e0a7560c102@mail.gmail.com>]
* Fwd: Puzzle about CFG on rtl during delay slot schedule [not found] ` <v2ue8b251c81004020340tf3fb7416s12756e0a7560c102@mail.gmail.com> @ 2010-04-02 10:41 ` Amker.Cheng 2010-04-02 11:26 ` Steven Bosscher 0 siblings, 1 reply; 7+ messages in thread From: Amker.Cheng @ 2010-04-02 10:41 UTC (permalink / raw) To: gcc, stevenb.gcc > The CFG is not maintained during delay slot scheduling. This is, in > fact, a very old and well-known problem. Look for any e-mail on this > list that mentions reorg.c :-) > Thanks, further more , It seems cfg are not maintained after delay slot scheduling. also find that problem just before final pass. -- Best Regards. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Puzzle about CFG on rtl during delay slot schedule 2010-04-02 10:41 ` Fwd: " Amker.Cheng @ 2010-04-02 11:26 ` Steven Bosscher 2010-04-02 14:26 ` Jeff Law 0 siblings, 1 reply; 7+ messages in thread From: Steven Bosscher @ 2010-04-02 11:26 UTC (permalink / raw) To: Amker.Cheng; +Cc: gcc On Fri, Apr 2, 2010 at 12:41 PM, Amker.Cheng <amker.cheng@gmail.com> wrote: >> The CFG is not maintained during delay slot scheduling. This is, in >> fact, a very old and well-known problem. Look for any e-mail on this >> list that mentions reorg.c :-) >> > Thanks, further more , It seems cfg are not maintained after delay > slot scheduling. > also find that problem just before final pass. Yes. The CFG is constructed on GIMPLE and then maintained all the way through to reorg.c (or actually pass_free_cfg). Once destroyed, we cannot resurrect the CFG. In a perfect world, reorg.c would get a rewrite and we'd maintain the CFG all the way through to final. But in practice, reorg.c is not the only problem (for example, var-tracking also destroys the CFG, as do most machine reorgs). Ciao! Steven ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Puzzle about CFG on rtl during delay slot schedule 2010-04-02 11:26 ` Steven Bosscher @ 2010-04-02 14:26 ` Jeff Law 2010-04-02 14:41 ` Steven Bosscher 0 siblings, 1 reply; 7+ messages in thread From: Jeff Law @ 2010-04-02 14:26 UTC (permalink / raw) To: Steven Bosscher; +Cc: Amker.Cheng, gcc On 04/02/10 05:26, Steven Bosscher wrote: > > Yes. The CFG is constructed on GIMPLE and then maintained all the way > through to reorg.c (or actually pass_free_cfg). Once destroyed, we > cannot resurrect the CFG. > > In a perfect world, reorg.c would get a rewrite and we'd maintain the > CFG all the way through to final. But in practice, reorg.c is not the > only problem (for example, var-tracking also destroys the CFG, as do > most machine reorgs). > And that rewrite would use standard, well known & understood dependence analysis. reorg's methods for determine what insns can go into delay slots is utterly insane and can get extremely expensive. jeff ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Puzzle about CFG on rtl during delay slot schedule 2010-04-02 14:26 ` Jeff Law @ 2010-04-02 14:41 ` Steven Bosscher 2010-04-04 6:49 ` Amker.Cheng 0 siblings, 1 reply; 7+ messages in thread From: Steven Bosscher @ 2010-04-02 14:41 UTC (permalink / raw) To: Jeff Law; +Cc: Amker.Cheng, gcc, Jakub Jelinek On Fri, Apr 2, 2010 at 4:26 PM, Jeff Law <law@redhat.com> wrote: > On 04/02/10 05:26, Steven Bosscher wrote: >> >> Yes. The CFG is constructed on GIMPLE and then maintained all the way >> through to reorg.c (or actually pass_free_cfg). Once destroyed, we >> cannot resurrect the CFG. >> >> In a perfect world, reorg.c would get a rewrite and we'd maintain the >> CFG all the way through to final. But in practice, reorg.c is not the >> only problem (for example, var-tracking also destroys the CFG, as do >> most machine reorgs). >> > > And that rewrite would use standard, well known & understood dependence > analysis. reorg's methods for determine what insns can go into delay slots > is utterly insane and can get extremely expensive. Indeed! But before anyone starts such an effort (IIUC one of the new MIPS people was thinking of this), right now it makes no sense to rewrite reorg.c because the CFG is already broken even before that point. The var-tracking changes from Alexandre and Jakub insert DEBUG_INSNs and NOTEs in the wrong place so that verify_flow_info() already doesn't pass anymore even before pass_free_cfg. Plus, the machine reorgs need rewriting. There are already some machine reorgs that resurrect the CFG (they can -- as long as you don't verify_flow_info()), because they run right after pass_free_cfg). I have patches to have an pass_early_free_cfg and a pass_late_free_cfg that I intend to submit for GCC 4.6. Once I figure out how to fix var-tracking, anyway... Cheng, can you explain what lead you to this "discovery", and what you're trying to achieve? Ciao! Steven ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Puzzle about CFG on rtl during delay slot schedule 2010-04-02 14:41 ` Steven Bosscher @ 2010-04-04 6:49 ` Amker.Cheng 0 siblings, 0 replies; 7+ messages in thread From: Amker.Cheng @ 2010-04-04 6:49 UTC (permalink / raw) To: Steven Bosscher; +Cc: Jeff Law, gcc, Jakub Jelinek > Cheng, can you explain what lead you to this "discovery", and what > you're trying to achieve? Thanks for all your enthusiastic explanation. Well, we are now trying to find our processor's critical timing path by running it at higher frequency than it was designed for. One timing prob we found is in following insn sequence : insn1 : insn_kind_a insn2 : memory access So, in order to find more timing prob, we wanna modify gcc to insert nop insn between that two insns. unfortunately, insn1 could be in delay slot, I have to do that job after delay slot scheduling, which results in the first message. BTW, the processor has no pipeline stall when branching, so I think the nop is totally necessary for our sake. Thanks again. -- Best Regards. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-04-04 6:49 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-04-02 9:29 Puzzle about CFG on rtl during delay slot schedule Amker.Cheng 2010-04-02 9:43 ` Steven Bosscher [not found] ` <v2ue8b251c81004020340tf3fb7416s12756e0a7560c102@mail.gmail.com> 2010-04-02 10:41 ` Fwd: " Amker.Cheng 2010-04-02 11:26 ` Steven Bosscher 2010-04-02 14:26 ` Jeff Law 2010-04-02 14:41 ` Steven Bosscher 2010-04-04 6:49 ` Amker.Cheng
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).