> 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
