2010/8/21 Arjan van de Ven <[email protected]>:
> On 8/20/2010 11:52 PM, Carsten Munk wrote:
>>
>> [this is -not- a SSSE3 discussion thread nor should it turn into one]
>>
>> We were having some discussions around in some bugs that things should
>> in general follow OBS project optflags/CFLAGS/CXXFLAGS. For MeeGo.com
>> builds this is naturally optimized for Atom.
>>
>> I noticed the following default patch (see further down) in MeeGo gcc,
>> which seems to make the optflags a bit of a null-op as it overrides
>> them for x86 anyway.
>>
>> Would it be saner to remove/disable this patch and solely rely on
>> CFLAGS/CXXFLAGS/optflags for MeeGo builds? This would be more
>> ecosystem-friendly and allow for proper flexibility of compilation
>> flags for any given target.
>>
>>
>
> having gcc default to the MeeGo defaults is actually very sane (yes I wrote
> this patch),
> and I do not think you can argue anything else than that to be honest.
>
>
> It would be the same as defaulting to -march=native, except that we don't
> build on native exactly (we build on Core i7 like boxes)...
>
> Having good defaults that we MeeGo want... are you really trying to argue
> against that?
>

Not disagreeing, but it seems a bit superfluous to have it in both OBS
project optflags and at same time hardcode this. I've seen similar
approaches to establishing ARMv5 baseline on ARM.

My approach stems from that we don't have a similar baseline patch in
ARM MeeGo GCC and we seem to get along fine with optimization (current
CXXFLAGS mangling bug excepted).

Practical objection to hardcoding like this is that it makes difficult
(in future), in case someone wanted to optimize for different (even
higher -march=/whatever) flags, would be unable to have it be MeeGo
compliant as we've modified the gcc packaging. Even though it would
run MeeGo binaries just fine as MeeGo defaults are lower.

I might have misunderstood the patch, but it does seem to hardcode
'ix86_tune_string = "atom";' and ix86_arch_string = "core2" without
ability to change for other -mtune or -march. And that seems like a
bit of a problem in my eyes from the practical objection point of
view.

Best regards,
Carsten Munk
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev

Reply via email to