[OE-core] [PATCH] gcc: Add ability for tune files to pass in configure options to gcc

[Richard Purdie]

On Mon, 2011-08-08 at 11:35 -0500, Kumar Gala wrote:
> On Aug 2, 2011, at 8:11 AM, Kumar Gala wrote:
> 
> > 
> > On Aug 1, 2011, at 11:57 AM, Richard Purdie wrote:
> > 
> >> On Mon, 2011-08-01 at 09:44 -0700, Tom Rini wrote:
> >>> On 08/01/2011 09:07 AM, Phil Blundell wrote:
> >>>> On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote:
> >>>>> Not sure I understand the statement about disambiguate the resulting compilers, on PPC where I intend to utilize this we'd have the toolchains already named something like:
> >>>> 
> >>>> The thing about disambiguating was that, if you're going to modify the
> >>>> configure opts for gcc-cross based (indirectly) on ${MACHINE} you need
> >>>> to consider what happens if you have a single build directory that's
> >>>> being used for multiple MACHINEs.
> >>> 
> >>> What, I think, Kumar is driving at is why are you saying MACHINE when
> >>> it's a per core tune he's doing.  eg, every e5500 would do --with-cpu=e5500
> >> 
> >> The question is whether we'd like to get to the point of having more
> >> toolchains or less toolchains. I'd personally like to get to the point
> >> of less toolchains (e.g. one per arch) rather than more of them. We
> >> already pass all the appropriate flags around in the ADT/sdk code and in
> >> our own cross builds, we could easily add those to the default target
> >> environment too. This would actually make it clearer what is going on to
> >> the end user too rather than hiding the details into the gcc
> >> compilation.
> >> 
> >> So all things considered, I don't think this is the best way to go...
> >> 
> > 
> > How is this done or exported to the user of an ADT/sdk toolchain?
> 
> I still dont understand the concern here.  GCC is already picking a
> default for -mcpu, so why is having a tune file pick a better default
> any issue?
> 
> If there is an explicit -mcpu or other options like -mtune, the
> setting of --with-cpu will get ignored.

There are two sides to this:

a) In the ppc case there isn't that much of an issue since the different
tunes tend to have their own very specific package architectures. It
likely therefore doesn't matter much if gcc is hardcoded to a given
default. It would matter more on certain arm combinations I can think of
depending on what got hardcoded as default.

b) There are very few circumstances you'd ever be in an environment
where the correct cpu flags weren't getting supplied (and we have sanity
checks to ensure they do). We want to be heading to wards less
toolchains, not more toolchains and the more we code into the toolchain,
the more different toolchain builds we'll need.

Whilst I can see the reason for wanting a), I worry it will mask issues
where the flags are missing and also cause more toolchain fragmentation
with people very likely to get the values wrong in the arm case. I'm
therefore reluctant.

Cheers,

Richard