Problem with Delayed Branch Scheduling

Problem with Delayed Branch Scheduling

[Balaji S]

Hi everybody,

I have a problem with delayed branch scheduling. Problem in a DSP porting which has VLIW instructions and delayed branches. While scheduling delayed branches, GCC (3.4.3) schedules an instruction which is a part of a VLIW instruction. Is this the problem of the following define_delay description?

(define_delay (eq_attr "type" "jump")
  [(eq_attr "type" "!jump") (nil) (nil)
   (eq_attr "type" "!jump") (nil) (nil)])


Thanks in advance,
Balaji Sivan

Re: Problem with Delayed Branch Scheduling

[Steven Bosscher]

On Monday 04 July 2005 07:59, Balaji S wrote:
> Hi everybody,
>
> I have a problem with delayed branch scheduling. Problem in a DSP porting
> which has VLIW instructions and delayed branches. While scheduling delayed
> branches, GCC (3.4.3) schedules an instruction which is a part of a VLIW
> instruction. Is this the problem of the following define_delay description?
>
> (define_delay (eq_attr "type" "jump")
>   [(eq_attr "type" "!jump") (nil) (nil)
>    (eq_attr "type" "!jump") (nil) (nil)])

Add an attribute to those instructions that cannot be in delay slots,
and change this define_delay to disallow instructions with that attr?

Gr.
Steven

Re: Problem with Delayed Branch Scheduling

[Balaji S]

_On 04-Jul-2005 15:31, Steven Bosscher san wrote_:
> 
> Add an attribute to those instructions that cannot be in delay slots,
> and change this define_delay to disallow instructions with that attr?

Any instruction other than jump can be placed in the delay slot. I hope "!jump" can fulfill this requirement.

I don't have any idea to identify a part of a VLIW instruction and disallow it delay slot. I only know that TImode of insn signifies a new cycle start. please hlep me by giving some pointers.

Re: Problem with Delayed Branch Scheduling

[Steven Bosscher]

On Monday 04 July 2005 12:41, Balaji S wrote:
> _On 04-Jul-2005 15:31, Steven Bosscher san wrote_:
> > Add an attribute to those instructions that cannot be in delay slots,
> > and change this define_delay to disallow instructions with that attr?
>
> Any instruction other than jump can be placed in the delay slot. I hope
> "!jump" can fulfill this requirement.
>
> I don't have any idea to identify a part of a VLIW instruction and disallow
> it delay slot. I only know that TImode of insn signifies a new cycle start.
> please hlep me by giving some pointers.

Ah, I think I misunderstood your problem.

So you have a few instructions bundled into a VLIW instruction, and
one of the instructions in the bundle is moved into the delay slot,
thus breaking your VLIW bundle.  Right?

That is a much harder problem...  I don't think it is really possible
with the existing dbr scheduling pass, but maybe someone else knows a
trick for this...

Gr.
Steven

Re: Problem with Delayed Branch Scheduling

[Ian Lance Taylor]

Steven Bosscher <stevenb@suse.de> writes:

> So you have a few instructions bundled into a VLIW instruction, and
> one of the instructions in the bundle is moved into the delay slot,
> thus breaking your VLIW bundle.  Right?

I think there are two natural approaches.

1) Do the VLIW bundling after delayed branch scheduling.  The way to
   do that is to the bundling in TARGET_ASM_FUNCTION_PROLOGUE.  The
   FRV backend does this.  I've done this successfully in the past.

2) When you do the VLIW bundling, put the instructions into a
   PARALLEL.

In general the gcc scheduler does not handle VLIW scheduling very
well, and it needs a fair amount of target specific help.

Ian

Re: Problem with Delayed Branch Scheduling

[Balaji S]

_On 05-Jul-2005 00:14, Ian Lance Taylor san wrote_:
> Steven Bosscher <stevenb@suse.de> writes:
> 
>>So you have a few instructions bundled into a VLIW instruction, and
>>one of the instructions in the bundle is moved into the delay slot,
>>thus breaking your VLIW bundle.  Right?
> 
> 
> I think there are two natural approaches.
> 
> 1) Do the VLIW bundling after delayed branch scheduling.  The way to
>    do that is to the bundling in TARGET_ASM_FUNCTION_PROLOGUE.  The
>    FRV backend does this.  I've done this successfully in the past.
I think this is a good workaround but nullifying the possibility of having a VLIW bundled instruction in a branch delay slot.

> 2) When you do the VLIW bundling, put the instructions into a
>    PARALLEL.
I think this is the right solution which rectifies the problems. Please provide the pointer to where it has to be done.

> In general the gcc scheduler does not handle VLIW scheduling very
> well, and it needs a fair amount of target specific help.
I dont know the list of known requirements (help), but from my side, currently insns are marked by TImode to signify the start of a VLIW bundle but some assemblers may require to signify the end of a VLIW bundle. There is no provision for that. Currently i have hacked GCC to meet this requirement.

Re: Problem with Delayed Branch Scheduling

[Richard Sandiford]

Ian Lance Taylor <ian@airs.com> writes:
> Steven Bosscher <stevenb@suse.de> writes:
>> So you have a few instructions bundled into a VLIW instruction, and
>> one of the instructions in the bundle is moved into the delay slot,
>> thus breaking your VLIW bundle.  Right?
>
> I think there are two natural approaches.
>
> 1) Do the VLIW bundling after delayed branch scheduling.  The way to
>    do that is to the bundling in TARGET_ASM_FUNCTION_PROLOGUE.  The
>    FRV backend does this.  I've done this successfully in the past.

To avoid any confusion: FR-V does indeed do the bundling here,
but FR-V doesn't have delay slots, and so it isn't affected the
OP's problem.  (I realise you weren't claiming otherwise.  I just
thought I'd better mention it explicitly.)

Richard

Re: Problem with Delayed Branch Scheduling

[Ian Lance Taylor]

Balaji S <sivanbalaji@acmet.com> writes:

> >>So you have a few instructions bundled into a VLIW instruction, and
> >>one of the instructions in the bundle is moved into the delay slot,
> >>thus breaking your VLIW bundle.  Right?
> > I think there are two natural approaches.
> > 1) Do the VLIW bundling after delayed branch scheduling.  The way to
> >    do that is to the bundling in TARGET_ASM_FUNCTION_PROLOGUE.  The
> >    FRV backend does this.  I've done this successfully in the past.
> I think this is a good workaround but nullifying the possibility of having a VLIW bundled instruction in a branch delay slot.

Well, you can have multiple instructions in a delay slot by pretending
that there are multiple delay slots.  You have to write the delay slot
conditions such that the selected instructions can always form a
bundle.  This is clearly getting a little tricky.

> > 2) When you do the VLIW bundling, put the instructions into a
> >    PARALLEL.
> I think this is the right solution which rectifies the problems. Please provide the pointer to where it has to be done.

I've never actually done it this way myself.  I guess the
TARGET_SCHED_FINISH hook would be the place to tie the instructions
together.

Ian

Re: Problem with Delayed Branch Scheduling

[Joern RENNECKE]

> So you have a few instructions bundled into a VLIW instruction, and
> one of the instructions in the bundle is moved into the delay slot,
> thus breaking your VLIW bundle.  Right?

> That is a much harder problem...  I don't think it is really possible
> with the existing dbr scheduling pass, but maybe someone else knows a
> trick for this...

So the problem is that we represent instructions that don't actually
exist as individual instructions?  I think it is legitimate to use
machine_dependent_reorg to make the actual instructions explicit.

However, in order to do this without exploding the machine description,
you'd probvably have to revive match_insn (the one formerly named
match_insn2).