This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 06/19/2013 06:51 PM, Roland McGrath wrote:
>> 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?

Lack of experience in dealing with such things?
 
>> 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.

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.

Your suggestion is a robust one though, I don't argue that, you assume
the compiler's behaviour, period.

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

Agreed, which is what makes it difficult for me to argue that the present
patch is robust, but it does work, it's a low-fidelity model of the same
situation.

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

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

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?

I'm not saying you're wrong, I'm trying to understand the inflection
point of the decision. You made a decision with a set of internalized
assumptions. I want to know if I can fix any of those assumptions in
the future.

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]