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

[law at redhat dot com]

In message <Pine.LNX.4.44.0310171250480.8672-100000@www.eyesopen.com>, Roger Sa
yle writes:
 >
 >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.
Understood.

 >
 >> 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.
Yes, I know.  We have this fundamental problem that a lot of things that
were previously done at the tree->rtl level really need to happen earlier
for tree-ssa.   And we fundamentally have two choices.

  1. Copy and update as needed.

  2. Do the work in both trees.

The first is faster, but introduces the merge problem.  The second is
insanely slow for fast moving development since every patch has to be
bootstrapped and tested twice, not to mention you have to worry about
what phase the mainline is in and whether or not your patch is suitable
for that phase.

I choose #1 for most of the folding stuff.  The single biggest limiting
factor for progress on tree-ssa at that time was bootstrap/testing.
Doubling the bootstrap/testing criteria would have slown things down
to a crawl.  I believe we are getting a lot closer to the point where
merging this kind of infrastructure makes sense.

Unfortunately, the same area has been very active in the mainline sources
as well which has significantly raised the cost of #1.  Sigh.

 >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.
That's certainly a good thing -- but it's not something I can really
tackle right now.  If you could help with that it would be a good thing.

The folders are probably the single biggest headache from a merge standpoint
right now.



 >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.
Really?  That would be a very pleasant surprise.

 >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.
No strong opinions here -- that's just a matter of engineering.

jeff