Patch: improve doloop detection

Roger Sayle roger@eyesopen.com
Fri Sep 12 01:46:00 GMT 2003


Dale Johannesen <dalej@apple.com> wrote:
> This allows loops controlled by (unsigned int--  >  0)
> to be detected as doloops.  Bootstrapped and tested on
> Darwin to the extent currently possible (no diffs before & after).
>
> 2003-09-11 Dale Johannesen <dalej@apple.com>
>
> * fold-const.c (fold): Move detection of unsigned>0, <=0 a bit earlier.

Hi Dale,

The ordering of constant folding optimizations in fold-const.c
shouldn't be normally be order dependent.  Typically, most
optimizations create a new tree using build or build1 and then
recursively call fold on the result.  This simplifies moving
transformations around in the source code.

Unfortunately, there are a handful of transformations that instead
of building a new tree and calling fold, treat the input tree as
mutable, modifying it in place using TREE_SET_CODE and similar
hacks.  This not only introduces an order dependence, and misses
optimization opportunities, but also creates problems if the tree
is shared or otherwise re-used by a front-end.

A practice that unfortunately your patch perpetuates...

Any chance that you could address the underlying cause of the
failure, by fixing whichever transformation isn't recursively
calling fold?

Essentially, this involves changing all of the places that
call "TREE_SET_CODE (t, code)" [and often the preceeding
copy_node (t)] into the much preferred:

	return fold (build (code, type, arg0, arg1));


As I'm neither a reviewer nor maintainer, feel free to ignore
the above comments, they're only a suggestion.

Many thanks in advance,

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833



More information about the Gcc-patches mailing list