On 05/19/11 13:01, Paul Koning wrote:
> 
> On May 19, 2011, at 6:41 AM, Paul Koning wrote:
> 
>>
>> On May 19, 2011, at 3:32 AM, Richard Sandiford wrote:
>>
>>> Paul Koning <paul_kon...@dell.com> writes:
>>>> ...
>>>
>>>> 2. In the delay slot fill machinery (reorg.c), I don't see how a
>>>> target can supply hooks to adjust the picking of one branch over
>>>> another.  In other words, if the architecture has branch-likely that
>>>> has annul, but that instruction should not be used in a particular
>>>> spot because the branch is in fact NOT likely, how would one do that?
>>>
>>> This isn't something that should be handled by target hooks.  The way
>>> that we record branch probabilities is target-independent, and reorg.c
>>> already knows whether the target has both annulled and non-annulled
>>> branches.
>>
>> I saw that.  But it looks to me like that logic picks one or the other 
>> depending on how that fills branch delay slots, and it does not take into 
>> account that the annulling branch on MIPS is supposed to be used (if at all) 
>> only when the branch is likely to be taken. 
> 
> That wasn't very clear, so let me restate it.  The current logic appears to 
> choose between non-annulling and annulling branches without taking into 
> account branch probability.  That may be fine on some platforms, but on MIPS 
> this is not supposed to be correct -- annulling branches (except in -Os) 
> should be used only when the branch is likely, and I don't see that.
> 
> Since the question of whether an annulling branch is appropriate depends on 
> the architecture -- the MIPS rule may not apply to other processors -- I was 
> thinking a target hook should be defined for this.

reorg hasn't ever had the kind of logic you're seeking.  It's general
goal has been to fill as many slots as possible.  When attempting to
fill a slot it takes the first insn that fits, first looking for insns
which are known to need to be executed regardless of branch direction,
then looking at other approaches to find suitable insns.

Now, there is a fairly powerful hook in that you can call out to
functions that can execute arbitrary code (via symbol_ref).  In theory,
you could use that capability to claim that an unlikely branch can not
have its delay slot annulled.


jeff

Reply via email to