[OE-core] gcc-runtime: Remove -mcpu=cortex-a7 when building for -march=armv7ve

[Khem Raj]

On Tue, May 29, 2018 at 1:12 PM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Tue, 2018-05-29 at 12:13 -0700, Khem Raj wrote:
>> On Tue, May 29, 2018 at 11:41 AM, Andre McCurdy <armccurdy at gmail.com>
>> wrote:
>> >
>> > This change looks wrong (or at least incomplete and lacking a
>> > decent
>> > explanation):
>> why do you think it is wrong ? I would be happy to make the
>> explanation more decent
>> if you have ideas please share.
>>
>> >
>> >
>> >   http://git.openembedded.org/openembedded-core/commit/?h=master-ne
>> > xt&id=fbec01f01fdad23d95271db063ee0a4d0ab44568
>> >
>> > It was never posted to the list but seems to have made it as far as
>> > master-next.
>
> I don't know where Ross got the patches from but I've taken over and he
> told me the patches in mut were ready. I didn't take this one however.

Thats right. since Ross has been testing gcc8 patchset
and reducing the number of patches needed for enabling gcc8 and this one seems
more benign, to go in independent of rest of gcc8 patches.

>
> My concern is the use of "remove" which I really prefer not to use in
> OE-Core. In core, its a sign that we have the overall structure wrong
> as we should never need to do this.

Yes and its a valid one. A better way would be to not use -mcpu for
recipes which
are not compiled for machine specifically, our tunes however are using
this extensively
and changing that probably should not be clubbed together with gcc
upgrade. the warning
emitted with gcc8 is just highlighting the problem that has been
latent. -mcpu is not
consistent across different architecture, x86 has removed it for arm
it means sum of
march+mtune etc.

on arm mcpu backfills either of march or mtune if not supplied on
cmdline, and in case
there are conflicts the rightmost setting wins, however this
precedence can then conflict
with builtin defaults, thats what we are seeing here.

I thought about proposing a separate series for removing -mtunes
atleast for arm. However such a change would
need very careful testing, since this can have runtime performance
impacts and other
optimization bugs etc. So regardless we should do it where we only use
-march and -mtune
combination which will let it target more broader spectrum of cpus and
users will be able
to generate pre-compiled binaries for larger base ISA so there are a
few advantages

leaving compiler do its job always results in best performing code in
my experience, adding
too many fine-tuning at global level are overkill anyway. apps ask for
specific opt flags themselves where needed, and if we have empirical
data where it proves helpful we can always do that at recipe level via
cflags.

>
> I'd like to understand why gcc-runtime needs this special treatment and
> whether there are other arm tunes which have the same issue? Should we
> be tweaking the main tune files in some way instead?
>

Yes we should be re-looking at how arm tune flles stagger various
compiler options
especially march/mtune/mcpu, but I would think that is a separate topic.

> Cheers,
>
> Richard
>
>