This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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