This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Reorder some tree codes


On Mon, 2004-12-20 at 07:53 -0800, Mark Mitchell wrote:
> would think that the subsequent accesses would hit in cache.)  I suspect 
> that the reason it made a big difference is that we avoided a lot of 
> branches in the compiler, which would explain the 2% text side 
> reduction.  So, we probably get better branch prediction, better icache 
> use, and fewer stalls.
That would be my suspicion as well.  Back when the range checking code
was added to fold-const.c I was able to show how it could actually
pessimize code and some hackery I did at the time to fix those
pessimizations resulted in a 1% improvement in code size.  And
(of course) the improvements in code size where from killing unnecessary
branches.

So I'm not terribly surprised to hear that reordering tree nodes could
result in a 2% improvement in text size and a measurable runtime
improvement.

For extra credit, can someone check and see if we get optimal code out
of this testcase for the branches, and if we don't, can we get a PR
filed :-)


typedef enum
{
  END = -1,
  EMPTY = (1 << 8 ) ,
  BACKREF,
  BEGLINE,
  ENDLINE,
  BEGWORD,
  ENDWORD,
  LIMWORD,
  NOTLIMWORD,
  QMARK,
  STAR,
  PLUS,
  REPMN,
  CAT,
  OR,
  ORTOP,
  LPAREN,
  RPAREN,
  CSET
} token;
static token tok;
static int
atom()
{
  if ((tok >= 0 && tok < (1 << 8 ) ) || tok >= CSET || tok == BACKREF
      || tok == BEGLINE || tok == ENDLINE || tok == BEGWORD
      || tok == ENDWORD || tok == LIMWORD || tok == NOTLIMWORD)
    return 1;
  else
    return 0;
}

[ Hint, if you've got more than 3 branches, then there's definitely too
  many. ]

Jeff






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]