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 18:41:15 -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>
On 06/19/2013 06:11 PM, Roland McGrath wrote:
>>> I'm a little worried about the fragility of the test, but if it doesn't
>>> optimize to memset, then it may not optimize the internal implementation
>>> to memset, and therefore we need not avoid the benefit of the optimization.
>>>
>>> I think this is a good approach, but we will have to see how it plays out
>>> and if it is robust enough.
>>
>> We might make it more robust (maybe trying different loops), do you think it
>> is worth to push more tests?
>
> I had not contemplated this sort of configure check and I don't think it's
> what we want at all. It doesn't matter whether the compiler actually
> transforms a particular case into a call. All that matters is that the
> compiler understands
> __attribute__ ((optimize ("-fno-tree-loop-distribute-patterns"))).
> If it does, then we'll use it every place we think it might matter.
Why isn't it what we want? Is it because it's fragile and only indirectly
tests if the actual optimization will be applied?
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.
What if we made the test look exactly like the way memset or memmove looks
when compiling in glibc? Would that have made the dynamic test sufficiently
robust?
I'm trying to understand the criteria you apply to such a decision.
Cheers,
Carlos.