Puzzle about CFG on rtl during delay slot schedule

Puzzle about CFG on rtl during delay slot schedule

[Amker.Cheng]

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.

Re: Puzzle about CFG on rtl during delay slot schedule

[Steven Bosscher]

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

Fwd: Puzzle about CFG on rtl during delay slot schedule

[Amker.Cheng]

> 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.

Re: Puzzle about CFG on rtl during delay slot schedule

[Steven Bosscher]

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

Re: Puzzle about CFG on rtl during delay slot schedule

[Jeff Law]

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

Re: Puzzle about CFG on rtl during delay slot schedule

[Steven Bosscher]

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

Re: Puzzle about CFG on rtl during delay slot schedule

[Amker.Cheng]

> 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.