This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] New code size estimate
- From: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>
- To: Steven Bosscher <stevenb at suse dot de>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 28 Feb 2005 16:04:18 +0100 (CET)
- Subject: Re: [PATCH] New code size estimate
On Mon, 28 Feb 2005, Steven Bosscher wrote:
> Ref: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01796.html
> > * tree-inline.c (estimate_num_insns_1): Ignore stores to decls with
> > ignored flag set.
> Someone still has to explain why this makes sense. All large
> expressions will now suddenly look really small, if I understand
> this change correctly. For example, say you have,
> x = a + b + c + d + e + .... + z;
> then the equivalent GIMPLE will look something like,
> t2 = a + b;
> t3 = t2 + c;
> x = t25 + z;
> and all the "t[0-9]+" temporaries would result in real code being
> generated, but their assignments would be ignored if this patch is
> applied, because all temporaries would have DECL_IGNORED set on
> them. Ignoring them would be not quite sane IMHO. Am I missing
> something here?
Sorry to followup myself again, there are certainly ways to improve
estimate_num_insns - f.i. we assign the same cost (1) to EXPR nodes
with any number of arguments, while it may be better (if we are
no longer counting those virtual stores) to assign 1 to NEGATE_EXPR
and 2 to ADD_EXPR, f.i., it also doesn't make much sense in my
view to assign 10 to RDIV_EXPR (for a code size estimate). But
changing too much at once is probably not a good idea.