This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Puzzle about CFG on rtl during delay slot schedule
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