Re: [PATCH] Fixes tree-loop-distribute-patterns issues

[Roland McGrath <roland at hack dot frob dot com>]

> Why isn't it what we want? Is it because it's fragile and only indirectly
> tests if the actual optimization will be applied?

Those are importantly bad things, yes.  But, really, why do you think that
it might be what we want?

> There appears to be a turning point at which you decide to just disable
> the optimization forever (until a human reviews the situation) instead of
> dynamically testing for what is actually wrong.

For this case, I really don't think it makes any kind of sense to
"dynamically test for what is actually wrong"--or perhaps even to think
that you ever could.  The real "what is actually wrong" is not a dynamic
thing.  It's statically true that it's wrong for the compiler to think it
has the option to emit a library call in these cases.

> What if we made the test look exactly like the way memset or memmove looks
> when compiling in glibc?

That's unmaintainable unless you take great pains to ensure that it is
actually the same source code compiled in exactly the same way in the test
and the actual code.

> Would that have made the dynamic test sufficiently robust?

I hesitate even to try to answer this question.  You're asking about the
details of a path that I'm sure is fundamentally wrong.


Thanks,
Roland