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


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