Re: [PATCH] Constant fold <string.h> library functions

[Roger Sayle <roger at eyesopen dot com>]

On Fri, 17 Oct 2003 law@redhat.com wrote:
> Now imagine actually having to write that stuff! :(

You have my sympathies.


>  >To use a random example, I took a quick peek at simplify_builtin_strcmp
>  >and it contains both the invalid strcmp  -> memcmp optimization, see
>  >http://gcc.gnu.org/ml/gcc-patches/2003-10/msg00188.html,
> Yes, that's a fairly recent thing that we're going to have to pick up.

It's been on mainline since April, so its only been six months.


> On tree-ssa the trees are unshared, which ought to make this safe.
> If it's really that offensive it wouldn't be terrible to generate a
> new argument list.

The problem is that since you undertook the impressive work of copying
all of this stuff out of the expand_builtin_foo functions, the originals
have evolved.  In some cases, significantly.  For example, the equivalent
code in expand_builtin_strcpy *does* build a new argument list, but its
ancestral "homolog" in simplify_builtin_strcpy still uses the original
(and potentially dangerous) chainon.


I think a significant priority is to eliminate this duplication and
synchronize builtins.c between mainline and tree-ssa.  This will fix
the current issues and prevent things getting any worse.

Perhaps the biggest (only?) thing blocking that is the use save_expr
in the routine fold_builtin_cabs, which may result in non-gimple trees
from fold_builtin, which otherwise is almost identical to tree-ssa's
simplify_builtin.

One possible solution here is to use a global variable to communicate
with the middle-end constant folding code such that it only produces
valid gimble trees, i.e. it disables all optimizations that require
save_expr etc...  This can be toggled on and off depending upon the
pass.


Thoughts?

Roger
--
Much like the Balkans and the Middle-East, constant-folding lies on the
volatile boundary between tree-ssa and the existing GCC infrastructure.