Re: [patches] powerpc 8xx dcbz problem

[Mark Hatle <mark.hatle@xxxxxxxxxxxxx>]

I think the key from a vendor point of view is to pick and choose our
battles.  If there are enough commonalities (userspace) between chips,
we'd prefer to have a common multilib.  As soon as the optimizations and
variations get too large to be reasonable, thats when the --with-cpu and
more variations make sense to me.

It's a fine line, and one that we have to agree to cross.  (Just my 2
cents..)

--Mark

Steven Munroe wrote:
> Mark Mitchell wrote:
>> Nathan Sidwell wrote:
>>   
>>> Steven Munroe wrote:
>>>
>>>     
>>>> So just provide a patch for sysdeps/powerpc/powerpc32/8xx/ to override
>>>> memset.S with a version that does not use dcbz. Then use -with-cpu=8xx
>>>> for you build. This elliminates the clutter to the base but solves your
>>>> chip specific problem!
>>>>       
>>> We're trying to avoid an 8xx-specific multilib here.
>>>     
>> Yes, we (and some of our customers) aren't eager to have lots of
>> multilibs; the goal is to have binaries that can run on a variety of
>> systems.  (That's why I was asking questions about dynamically selecting
>> optimization strategies a while back.)
>>   
> yes but!
> 
> there is near infinite variation in the embedded space and managing this
> will be major problem if each chip's has to have chip specific code fix
> in the sprinked all over the common code. That is why Roland agreed to
> add the --with-cpu support as a way to manage this. You all might be
> very annoyed with me, if I had 970/power4/power5/power5+/power6/power6x
> specific code cluttering up performance sensitive common code!
>> Even if it's not practical to dynamically choose optimized code paths, I
>> think it's important to be able to do some dynamic selection for cases
>> like this.  Obviously, it's unfortunate that 8xx processors have this
>> bug, but they do, and being able to distribute a single binary for a
>> family of processors is an important convenience.
>>
>>   
> So any fix/work-around should go in ports and should use --with-cpu. You
> can override libc-start.c from ports/sysdeps/powerpc/powerpc32/8xx with
> a version that zeros __cache_line_size for 8xx and sets its from
> AT_DCACHEBSIZE otherwise.
> 
> This allows you to build a single binary, but keeps the trunc clean.