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: BELBACHIR Selim <selim dot belbachir at fr dot thalesgroup dot com>
- To: Jeff Law <law at redhat dot com>, Eric Botcazou <ebotcazou at adacore dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 14 Oct 2013 14:24:18 +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> <2486289 dot gZRegTf76f at polaris> <21846_1381492280_5257E638_21846_530_1_9C88BF562A27AA41B242B2780441926E2102E89256 at THSONEA01CMS05P dot one dot grp> <5258609F dot 70903 at redhat dot com>
Thanks for the hints !
I found a recent correction on resource.c ' https://github.com/mirrors/gcc/commit/d8e17376c1b6ba379cc918f06843792e35c4e38e' which treat my problem.
It seems my problem was not related to my parallel compare insn but produced by the conditional call at the beginning of the target path.
Let's hope this correction does not hide another problem by just applying a side effect on my specific test case :)
Regards,
Selim
-----Message d'origine-----
De : Jeff Law [mailto:law@redhat.com]
Envoyé : vendredi 11 octobre 2013 22:34
À : BELBACHIR Selim; Eric Botcazou
Cc : gcc@gcc.gnu.org
Objet : Re: delay slot of conditionnal branch with no annuled jump strategy
On 10/11/13 05:51, BELBACHIR Selim wrote:
>
>> Does this happen systematically with the compare insn or is it isolated?
>
> I encountered this problem only once in gcc testsuite (gcc.c-torture/execute/builtins/strncat-chk.c).
> I think the problem is quite rare because gcc does not put often a
> parallel compare insn into the delay slot of a conditional jump, and when it happens it's not certain that the register clobbered by the parallel compare is used in the fall-through path after the conditional jump.
> So I would say the problem is isolated.
>
>> 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.
>
> My current investigation showed that when I comment the call to 'fill_eager_delay_slots' in ' reorg.c:dbr_schedule' the problem disappear.
> The problem does not come from the 2 others techniques for filling delay slots : 'fill_simple_delay_slots' or 'relax_delay_slots'.
>
> To illustrate the problem previously described in asm, I copied and commented the rtl dumps below :
I'd look at the code in resource.c very carefully, it's possible it's not properly handling all the side effects of the parallel.
jeff