[OE-core] MIPS vs MIPS32 tunings -- summary and questions

[Andreas Oberritter]

On 10.04.2012 21:28, Andreas Oberritter wrote:
> On 10.04.2012 19:53, Mark Hatle wrote:
>> We still do not have a clean answer for how to resolve the concerns in
>> the recent thread "conf/machine/include: Cleanup MIPS tunings to match
>> README".  The following is in response to a request I received to
>> summarize the discussion so far, and include the options to resolve the
>> issue for the current OE-Core release.
>>
>> If you are interested in this, please be sure to read until the end
>> before commenting.
>>
>> Background:
>>
>> About 2 weeks ago, in response to a number of patches sent for PowerPC
>> issues, I set to the task of documenting and cleaning up the various
>> tune files.  It was discovered that since they were originally
>> implemented, a number of minor conflicts and defects had crept into the
>> system.  The recent patch set added a number of README files and
>> attempted to resolve any duplication, or confusion between items.
>>
>> During this work it was discovered that there were two tunings that
>> produced the same package architecture:
>>
>> mips (tune), optimized for mips1 - o32 ABI, produced packages with a
>> "mips" arch
>>
>> mips32 (tune), optimized for mips32 - o32 ABI, produced packages also
>> with a "mips" arch.
>>
>> While "mips1" should work on a "mips32" system, the reverse is not
>> true.  There was no way to distinguish, in a package feed, the
>> difference between the two sets of binaries.
>>
>> I updated the MIPS tune files to resolve this issue.  The result was:
>>
>> mips (tune), mips1 - o32 ABI, produced packages with a "mips" arch
>>
>> mips32 (tune), mips32 - o32 ABI, produced packages with a "mips32" arch
>>
>> This lead to the thread mentioned above.  At first there were concerns
>> that the GNU target arch had changed (from mips to mips32), this was not
>> the case.  The only change is in the produced package arch names.  So
>> the package feeds and image generation are the only components affected
>> by this change.
>>
>> After various discussion with folks, such as Khem Raj, it is unlikely
>> that anyone would be using oe-core with a "mips1" target.  There may be
>> some mips3 or mips4 targets, but we find it highly unlikely based on our
>> current experience. Khem suggested resolving this my simply making the
>> "mips" include mips32 as the default optimization.
>>
>> Image generation was verified to produce the same images before and
>> after this change for the qemumips target.  I am unable to verify the
>> package feeds, as I do not have a suitable setup for this.
>>
>> So possible solutions to this particular issue, which we do need on
>> prior to the upcoming release:
>>
>> 1) Revert the behavior and match that last release.  We have two tunes
>> that produce different binaries w/ the same "mips" package arch.
>>    * This preserves previous behavior, but IMHO continues to implement
>> the defect
>>
>> mips (tune) - mips1 processor, o32 ABI - mips package arch
>> mips32 (tune) - mips32 processor, o32 ABI - mips package arch
>>
>> 2) Keep it as it is currently checked in.  Provide the ability to build
>> a basic "mips" and a more optimized "mips32" tuned target and package set.
>>    * This fixes the defect and provides the opportunity for "mips" to be
>> a basic common package arch, while mips32 (or additional mips3? mips4?
>> mips32r2?) tunes could be used to augment this for specific systems.
>>
>> mips (tune) - mips1 processor, o32 ABI - mips package arch
>> mips32 (tune) - mips32 processor, o32 ABI - mips32 package arch
> 
> If the tune should reflect the optimization, then mips should be renamed
> to mips1 and specified explicitly using -march=mips1, in order to
> protect against changing defaults when using a newer compiler. However,
> as Phil pointed out, there are many more optimization settings, e.g. -O2
> vs. -Os, that aren't encoded into the package arch, so the goal to have
> distinct package archs for different binaries won't be reached.
> 
> I don't see what a common "mips" package arch would give us. Within OE,
> you'd usually compile all your applications for the package arch of your
> target system. Adding compatible package archs to the feed just
> increases the complexity of online updates.
> 
>> 3) Define only one mips tune, with a target package arch of "mips". 
>> Changing the basic mips tune, and corresponding mips package arch to
>> include mips32 optimizations and instructions.
>>    * This preserves the "mips" tune, but changes the behavior of the
>> tune from default compiler, to mips32 optimization
>>    * Anyone requiring mips3 or mips4 will need to add a tune, and that
>> tune will not be compatible with "mips"
> 
> Also, mips1 could be added back anytime if anybody starts using it.
> 
>> mips (tune) - mips32 processor, o32 ABI - mips package arch
>>
>>   3a) Preserve the mips32 tune entries, but define it as being equal to
>> mips
>>       * Preserves the tune entries for compatibility, but is anyone
>> directly using them?
>>
>>   3b) Remove the mips32 tune entries -- effectively eliminating mips32
>> as a tune
>>       * Removes the tune entries (cleans up the tunes), no compatibility
>> -- but it's unlikely anyone was directly specifying "mips32" as their
>> machine's DEFAULTTUNE.
> 
> Actually I have (had) machines specifying mips32el and mips32el-nf as
> their DEFAULTTUNEs, which your first patch, that got applied upstream,
> broke. But I've already switched to use your latest patch using mipsel
> and mipsel-nf instead, (which I prefer over the former).
> 
>> My recommendation is either 2 or 3.  The 3a/b variation is simply an
>> implementation detail to me, and I will be happy to implement it either
>> way if this is the chosen direction.
> 
> I'm fine with either way that restores mips/mipsel for mips32 targets
> *before the release*, because the online update feeds broke and all
> packages had to be built again from scratch.

Richard, can you please state your opinion about this issue?

The mips package feed (e.g. qemumips) is now broken since weeks. Can I
expect this to be corrected before the release, or should anybody
relying on mipsel package feeds stop using oe-core's
meta/conf/machine/include/mips/arch-mips.inc?

Regards,
Andreas