GCC Bugzilla has been upgraded from version 4.4.9 to 5.0rc3. If you see any problem, please report it to bug 64968.
Bug 38264 - tree_forwarder_block_p says no to first basic block
Summary: tree_forwarder_block_p says no to first basic block
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.4.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: missed-optimization
Depends on:
Blocks:
 
Reported: 2008-11-25 19:10 UTC by Richard Biener
Modified: 2012-02-02 17:58 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-02-02 00:00:00


Attachments
patch (1.02 KB, patch)
2008-11-25 19:11 UTC, Richard Biener
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Biener 2008-11-25 19:10:45 UTC
tree_forwarder_block_p has

  if (find_edge (ENTRY_BLOCK_PTR, bb))
    return false;

without explanation.  This test was added by you, Jeff - do you remember why?

Removing this check triggers some ICEs in the testsuite because remove_bb
(called from remove_forwarder_block) unconditionally moves labels from the
removed block to prev_bb (yuck!) - which is of course invalid if that happens
to be the entry bb.  Luckily remove_forwarder_block already contains code
to do the label-move job itself - it is just conditional on seen abnormal
incoming edges.  Enabling this code to run by default causes a bootstrap
comparison failure though.
Comment 1 Richard Biener 2008-11-25 19:11:25 UTC
Created attachment 16767 [details]
patch

Patch that miscompares.
Comment 2 Jeffrey A. Law 2008-11-25 20:04:29 UTC
Subject: Re:   New: tree_forwarder_block_p says no to
 first basic block

rguenth at gcc dot gnu dot org wrote:
> tree_forwarder_block_p has
>
>   if (find_edge (ENTRY_BLOCK_PTR, bb))
>     return false;
>
> without explanation.  This test was added by you, Jeff - do you remember why?
>
> Removing this check triggers some ICEs in the testsuite because remove_bb
> (called from remove_forwarder_block) unconditionally moves labels from the
> removed block to prev_bb (yuck!) - which is of course invalid if that happens
> to be the entry bb.  Luckily remove_forwarder_block already contains code
> to do the label-move job itself - it is just conditional on seen abnormal
> incoming edges.  Enabling this code to run by default causes a bootstrap
> comparison failure though.
>
>
>   
I'm not sure -- that code was introduced in 2003 and looks like it was a 
mix of some of Zdenek's work as well as mine.  It could well have been 
the label issue, or some horrid problem dealing with our control 
structures (which were still in the IL at that time), or simply my 
mis-translation of some of Zdenek's code.

Clearly remove_bb has to do something with the labels.  I think it was 
decided that the labels could go anywhere and the previous block 
reasonably convenient -- the theory was the block was unreachable, so 
the location of a named label in the block was unimportant.  In the case 
of a forwarder block the label was reachable and needs to be moved into 
a sane location -- removal of forwarder blocks probably wasn't something 
we considered when discussing the named label issues.

Jeff


Comment 3 Andrew Pinski 2012-02-02 17:58:52 UTC
Confirmed.
The code looks slightly different now as find_edge has been inlined and merged with checking for eh edges.