Re: optimization/9319: slower code generated for simple loop on linux

[Eric Botcazou <ebotcazou at libertysurf dot fr>]

The following reply was made to PR optimization/9319; it has been noted by GNATS.

From: Eric Botcazou <ebotcazou@libertysurf.fr>
To: Richard Henderson <rth@redhat.com>
Cc: Amnon Cohen <amnon_cohen@yahoo.com>,
 gcc-bugs@gcc.gnu.org,
 nobody@gcc.gnu.org,
 gcc-gnats@gcc.gnu.org
Subject: Re: optimization/9319: slower code generated for simple loop on linux
Date: Wed, 22 Jan 2003 00:09:52 +0100

 > I don't think it's worth much time.  The only way to Really Fix
 > this is to move to CFG-based loop analysis.
 
 Yes, and the pessimization is a direct effect of the patch, not a mere si=
 de=20
 effect. Before, loops such as
 
 =09top:
  =09   /* empty */
 =09body:
 =09   if (!cond) goto end;
 =09   statement;
 =09   goto top;
 =09end:
 
 were rotated, identically to canonical loops such as
 
 =09top:
  =09   if (!cond) goto end;
 =09body:
 =09   statement;
 =09   goto top;
 =09end:
 
 into
 
 =09   goto first;
 =09top:
 =09   statement;
 =09first:
 =09   if (cond) goto top;
 
 
 Now the patch explicitly forbids that, in order to preserve the unrolling=
 =20
 pass:
 
 !      We rely on the presence of NOTE_INSN_LOOP_END_TOP_COND to mark
 !      the end of the entry condtional.  Without this, our lexical scan
 !      can't tell the difference between an entry conditional and a
 !      body conditional that exits the loop.  Mistaking the two means
 !      that we can misplace the NOTE_INSN_LOOP_CONT note, which can=20
 !      screw up loop unrolling.
 
 
 Would you support relaxing the code when unrolling is disabled, in order =
 to=20
 recover the optimization loss in that case ?
 
 --=20
 Eric Botcazou