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

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

> > 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.
> 
> That truth isn't strictly tied to the option itself, it is tied to a
> compiler behaviour. We can't know the compiler behaviour unless we test
> that behaviour.

We don't need to know it.  We need to constrain it.

> Say in 5 years gcc grows the ability to optimize memset into a set of
> optimal vector libcalls? The test as it was proposed would detect that
> memset was no longer called, avoid the workaround, and we'd get a faster
> memset (albeit tied to whatever compiler runtime has the libcalls, think
> libgcc, think ARM compiler helper routines).

Burn that bridge when we come to it? ;-)

I am far more concerned about today's libc becoming unbuildable with a
future compiler than I am about today's libc being optimized by a future
compiler no better than it is by today's compilers.

The conservative assumption is that those hypothetical future other
outcalls will themselves be implemented using standard libc functions and
create an indirect circularity.

> The turning point though would be if we had enough framework in place
> for me to invoke a compilation of memset from the actual glibc source
> as part of the configure and test if the failure was present?

Perhaps something like that.  At that point I think we would not do it in
configure at all.  It could be in the build process itself.  For example,
compile each function without optimization, collect the list of external
references it generates that way, then compile with optimization and see if
it started calling things the unoptimized version didn't call; if it did,
annotate it to inhibit the optimizations suspected of producing them (it
could even be iterative for a set of possible annotations).  Not to get
into the details of the hypothetical right now, just an example.  The short
version is to say a dynamic approach is acceptable if it's completely
robust (in a maintainable way).


Thanks,
Roland