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

["Carlos O'Donell" <carlos at redhat dot com>]

On 06/19/2013 07:22 PM, Roland McGrath wrote:
>>> 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.

Thanks, that clarifies your position better than anything else you've said.
 
>> 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? ;-)

Heh. OK, agreed :-)

> 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.

That's something I hadn't considered, and it's a good point.

>> 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).

Thank you for indulging this line of thinking. It certainly gives me idea
for future enhancements.

Cheers,
Carlos.