[OE-core] [PATCH] arch-arm: Do not add -march options for arm architecture

[Richard Purdie]

On Thu, 2019-01-24 at 22:22 -0500, Khem Raj wrote:
> On Wed, Jan 23, 2019 at 6:11 PM Andre McCurdy <armccurdy at gmail.com>
> wrote:
> > On Wed, Jan 23, 2019 at 2:50 PM Khem Raj <raj.khem at gmail.com>
> > wrote:
> > > On Wed, Jan 23, 2019 at 5:27 PM Andre McCurdy <
> > > armccurdy at gmail.com> wrote:
> > > > On Wed, Jan 23, 2019 at 12:05 PM Khem Raj <raj.khem at gmail.com>
> > > > wrote:
> > > > > tune files which inherit the arch definitions already define
> > > > > appropriate
> > > > > -mcpu option, which is equivalent of right -march and -mtune
> > > > > combination
> > > > 
> > > > And what about machines which inherit an arch definition
> > > > instead of a
> > > > cpu definition? Is that no longer supported?
> > > 
> > > I could not find such a machine configuration in several BSP
> > > layers I looked at.
> > > Do you know of machine definitions where these files are included
> > > directly in machine configs ?
> > 
> > Using a CPU specific include but then leaving the generic
> > DEFAULTTUNE
> > (ie not enabling any CPU specific TUNE_CCARGS) is equivalent, and I
> > guess quite common.
> 
> defaulttune does not play much part in appending -mcpu option to
> compiler flags, A case
> where this could bypass the setting mcpu is when we do not include a
> tune-* for arm based machine
> and thats the case I was interested to know.
> 
> again if there is such a BSP I would be interested to test it out.
> > > if so, then we have to either use _remove or introduce a weak
> > > variable
> > > to set march only if
> > > mcpu is not set which
> > 
> > I think the solution is to ensure that the CPU specific tuning
> > options
> > are always compatible with any architecture specific options which
> > may
> > be active.
> > 
> > In general our CPU specific tuning files are a little sloppy (e.g.
> > defaulting to combinations of VFP versions and architecture levels
> > which never exist in the real world). If newer versions of gcc are
> > making those issues more apparent then why not take the opportunity
> > to
> > fix them properly?
> 
> the mcpu option is helping with right march/mtune combination. while
> we can
> use specific -march=arch(+-)features syntax and combine with right
> -mtune to match -mcpu I think we should use
> compiler defaults and not try to recreate something that -mcpu would
> do it easily for us.
> 
> So either we drop the idea of setting mcpu and use basic -march value
> combined with -mtune ( which btw. was default in past)
> or if we want to let compiler use ISA for a particular arch
> implementation ( cortexXXX ) then we should just use -mcpu and drop
> using -mtune and -march.
> 
> I would include towards option 1.

I think the friction is partly because we support "generic" tunes as
well as cpu specific ones. Having a system which allows all of these to
be switched between is hard.

I do agree we need to have a system which does one or the other and is
clearer than the current setup though.

The v2 patch isn't right as it will only work for one end result case
and won't dynamically adjust as the current code is designed to do. We
can fix that and make such a patch work, we just need to decide what
we're aiming for first and document it.

I'd also love to understand which of the tunes are actually used and
which ones we could prune out...

Cheers,

Richard