This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fixes tree-loop-distribute-patterns issues
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, "GNU C. Library" <libc-alpha at sourceware dot org>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Wed, 19 Jun 2013 19:01:10 -0400
- Subject: Re: [PATCH] Fixes tree-loop-distribute-patterns issues
- References: <51C0AFB7 dot 1060009 at linux dot vnet dot ibm dot com> <20130618205608 dot 9CCE22C0AC at topped-with-meat dot com> <51C1BFE9 dot 4070805 at linux dot vnet dot ibm dot com> <51C1CEFC dot 9000100 at redhat dot com> <51C1FE4C dot 3020400 at linux dot vnet dot ibm dot com> <20130619221130 dot 7B91A2C10E at topped-with-meat dot com> <51C2338B dot 4040304 at redhat dot com> <20130619225134 dot B7FBB2C111 at topped-with-meat dot com>
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.