[PATCH fortran] Use fold_build everywhere

[Richard Guenther]

On Sun, Feb 24, 2008 at 5:39 PM, Tobias Schlüter
<tobias.schlueter@physik.uni-muenchen.de> wrote:
> FX Coudert wrote:
>  >> Attached is an updated version of the patch which also modifies the
>  >> copyright years of the touched files and which fixes a typo I made
>  >> when I tried to fix formatting in the diff.
>  >
>  > My understanding was that the copyright years in the files need to
>  > include year X iff a release of the codebase is done in year X,
>  > independently of whether the file was actually modified or not. From
>  > http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html:
>  >> To update the list of year numbers, add each year in which you have
>  >> made nontrivial changes to the package. (Here we assume you're using a
>  >> publicly accessible revision control server, so that every revision
>  >> installed is also immediately and automatically published.) When you
>  >> add the new year, it is not required to keep track which files have
>  >> seen significant changes in the new year and which have not. It is
>  >> recommended and simpler to add the new year to all files in the
>  >> package, and be done with it for the rest of the year.
>
>  Well, that doesn't make wrong what I did :-)  Certainly it's better than
>  not updating the numbers at all.  I will take care of the rest later today.
>
>
>  >
>  > Other than that, the patch is OK. To satisfy my curiosity: I sometimes
>  > used buildN() instead of fold_buildN() when I know that the expression
>  > can't be simplified, to avoid extra burden on the middle-end, was that
>  > wrong or is it just that the benefit is too small to notice?
>
>  Last I checked the optimizers eat practically all the time in a
>  compilation, so it's not important time-wise.  Note that (at least
>  according to my understanding) fold_* would more appropriately be called
>  canonicalize_*, i.e. not only does it fold trees with constant
>  arguments, it also puts trees into standard forms by replacing
>  expressions with equivalent ones (say, something like (!a && !b) -> !(a
>  || b)).  Therefore, folding may have benefits even for non-constant
>  arguments.

It also for example reorders a + b iff b + a is the canonical form
(based on some
sorting criteria).  operand_equal_p for example relies on this
canonical ordering
and otherwise doesn't consider a + b and b + a the same.

Richard.