This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: delay slot of conditionnal branch with no annuled jump strategy
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: BELBACHIR Selim <selim dot belbachir at fr dot thalesgroup dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 10 Oct 2013 16:18:24 +0200
- Subject: Re: delay slot of conditionnal branch with no annuled jump strategy
- Authentication-results: sourceware.org; auth=none
- References: <12987_1381411882_5256AC2A_12987_783_1_9C88BF562A27AA41B242B2780441926E2102E03CD4 at THSONEA01CMS05P dot one dot grp>
> Here is a sample of erroneous code :
>
>
> sub 0,$R5,$R1 #compare $R5 to 0 ($R1 is clobbered)
> jmpd.ifCC .L0 #conditionnal delayed branch followed by 1
> delay slot sub $R0,$R4,$R0 #compare $R4 to $R0 ($R0 is clobbered)
> <<<< problem ...
> addk 1,$R0,$R0 #increment $R0, but $R0 was modified by 'sub
> $R0,$R4,$R0' !!! ...
> .L0:
> bra.ifLS __chk_fail #conditionnal call symbol_ref
>
>
> GCC put my compare insn 'sub $R0,$R4,$R0' into the delay slot knowing that
> $R0 was clobbered by the compare insn (see the definition below). It's ok
> if 'jmpd.ifCC .L7' jumps otherwize it's ko because $R0 is used in the
> fall-through path by 'addk 1,$R0,$R0'.
Does this happen systematically with the compare insn or is it isolated?
> Why GCC doesn't see, in this case, that it's not safe to fill the delay slot
> with my compare insn (which is a parallel RTX which clobber one register
> used in fallthrough branch) ? Is a processor 'annuled jump strategy'
> mandatory to handle delay slot of conditionnal jump instructions ?
This looks like a bug in the dbr pass (several of them have been fixed since
4.5.2) but it's impossible to be more precise without further details. The
support of annulled instructions is not required for proper operation.
--
Eric Botcazou