This is the mail archive of the gcc@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: fold_build


Hi Zdenek,

> this is hardly suprising, given the definition of fold_buildN as
> 
> +tree
> +fold_build2 (enum tree_code code, tree type, tree arg0, tree arg1)
> +{
> +  tree built_tree = build2 (code, type, arg0, arg1);
> +  tree folded_tree = fold (built_tree);
> +  total_fold_build++;
> +  if (built_tree != folded_tree)
> +    built_tree_not_returned++;
> +  return folded_tree;
> +}

Oops, I sent you a wrong version that I used to count how many nodes I
can avoid creating.  Nevertheless, this version does most of the
legwork needed for final versions of fold_buildN that do not create
scratch nodes.

One time I did go as far as writing fold_unary, fold_binary, etc, to
avoid creating scratch nodes, and then compile time improvement was
unmeasurable, but I don't seem to be able to find that patch. :-( But
let's do it again.  More careful analysis should find inefficiencies
here and there.

> Could you please polish it and submit (if you lack time, I may do it
> myself)? By itself this is a nice cleanup, and a necessary step for the
> further work described above -- it just does not make sense that someone
> eles should eventually spend time again with mechanical rewriting of
> fold (build (...)).

Sure.

Kazu Hirata


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