linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Kumar Gala <kumar.gala@freescale.com>
To: "Tom Rini" <trini@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] Set cpu explicitly in kernel compiles
Date: Thu, 5 May 2005 11:22:38 -0500	[thread overview]
Message-ID: <bc56e4a30aef8a46e88cee672a315fdc@freescale.com> (raw)
In-Reply-To: <20050505152709.GA1221@smtp.west.cox.net>


On May 5, 2005, at 10:27 AM, Tom Rini wrote:

> On Thu, May 05, 2005 at 10:12:42AM -0500, Kumar Gala wrote:
>  >
> > On May 5, 2005, at 9:23 AM, Tom Rini wrote:
>  >
> > >On Thu, May 05, 2005 at 09:00:50AM -0500, Kumar Gala wrote:
>  > > >
>  > >> On May 5, 2005, at 7:24 AM, Dan Malek wrote:
>  > > >
>  > >> >
>  > > > >
>  > > > >On May 5, 2005, at 1:22 AM, Paul Mackerras wrote:
>  > > > > > If you think we should have -mcpu=xxx on the command line 
> for
> > >4xx,
>  > > > > > 44x, 8xx, etc., then that's fine, but that is a separate 
> problem
>  > >> >from
>  > > > > > what my patch was addressing (one which my patch might make 
> it
>  > >> >easier
>  > > > > > to fix, though).
>  > > > >
>  > > > >I think that is exactly what we want, although I don't know how
> > >that is
>  > > > > separate from the patch you sent.? My original comment was the
> > >patch
>  > > > > fixes the problem for only one of the cpu cores, not all of 
> them.?
>  > >> >Which
>  > > > > then led into the subsequent suggestion of making the biarch 
> work
>  > > > > like the past compilers, and we must specific the flags for 
> POWER4
>  > > > > instead of the other way around.? Without explicit -mcpu 
> flags,
> > >the
>  > > > > existing compiler behavior is just fine .....? but, I guess 
> I'd be
>  > > > >standing
>  > > > > in the way of progress to want this :-)
>  > > >
>  > >> I agree with Dan here.? I think we should go ahead and extend the
> > >patch
>  > >> to set -mcpu and -mtune flags for the list of processors we have 
> in
>  > >> "Processor Type".? If I'm building a kernel for e500 or 4xx I 
> might
> > >as
>  > >> well get a kernel that is tuned a bit more for the subarch.?
>  > >
>  > > This is fine.
> > >
>  > >> Additionally, there should be some expert override ability, so 
> if I
>  > >> really want to do -mcpu=7455 -mtune=7455 I can.
>  > >
>  > >Gack, no!? It's quite a pain to go from CONFIG_FOO="string" into
> > >useable
>  > > Makefile bits that the one we did have back in 2.4 is gone.? That 
> also
>  > > implies gcc finally knows something about these cores that might 
> be
>  > > useful, which I don't think is the case, nor is it likely to be.? 
> But
> > >if
>  > > we did want it, we'd probably go the route x86 has.
>  >
> > I'm not saying it has to be done via a CONFIG option, all I'm saying 
> is
> > if I want to explicitly use GCC then I would hope we could somehow
> > disable it being override.
>
> If you're not doing it via CONFIG, that leaves manual (which is always
>  an option) or seeing if passing CFLAGS on the cmdline overrides 
> things,
>  or adds to them.

Thats all I really want.  Just for us to make sure if I want to do 
-mcpu=7455 -mtune=7455 I'm able to and it actually does what I told it 
to do.  I'm not sure if GCC is consistent on how it handles args that 
are duplicated.  For example what will happen with the following:

gcc -mcpu=750 -mtune=7450 -mcpu=603 -mtune=603

Is this -mcpu=750 -mtune=7450 or -mcpu=603 -mtune=603

- kumar

  reply	other threads:[~2005-05-05 16:22 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-04  7:05 [PATCH] Set cpu explicitly in kernel compiles Paul Mackerras
2005-05-04 11:28 ` Dan Malek
2005-05-04 15:34   ` Tom Rini
2005-05-04 16:06     ` Chris Friesen
2005-05-04 21:36   ` Paul Mackerras
2005-05-04 23:21     ` Dan Malek
2005-05-05  4:00       ` Paul Mackerras
2005-05-05  4:12         ` Tom Rini
2005-05-05  4:44           ` Paul Mackerras
2005-05-05  4:47             ` Tom Rini
2005-05-05  5:22               ` Paul Mackerras
2005-05-05 12:24                 ` Dan Malek
2005-05-05 14:00                   ` Kumar Gala
2005-05-05 14:23                     ` Tom Rini
2005-05-05 15:12                       ` Kumar Gala
2005-05-05 15:27                         ` Tom Rini
2005-05-05 16:22                           ` Kumar Gala [this message]
2005-05-05 16:29                             ` Tom Rini
2005-05-06 14:44                 ` Segher Boessenkool
2005-05-06 14:53                   ` Tom Rini
2005-05-06 15:28                     ` Segher Boessenkool
2005-05-06 15:34                       ` Tom Rini
2005-05-06 15:47                     ` Kumar Gala
2005-05-05 12:12             ` Dan Malek
2005-05-04 13:45 ` Kumar Gala
2005-05-04 15:28   ` Tom Rini
2005-07-03 17:29 ` Olaf Hering
2005-07-03 18:32   ` Tom Rini
2005-07-05 18:14     ` Olaf Hering
2005-07-05 19:47       ` Tom Rini
2005-07-05 19:54         ` Olaf Hering
2005-07-05 19:58           ` Tom Rini
2005-07-05 20:17             ` Olaf Hering
2005-07-05 20:27             ` Olaf Hering
2005-07-05 21:22               ` Tom Rini
2005-07-06  6:38                 ` Olaf Hering
2006-04-02 19:40 ` Olaf Hering
2006-04-06  4:37   ` Paul Mackerras
2006-04-11 18:42     ` Olaf Hering

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bc56e4a30aef8a46e88cee672a315fdc@freescale.com \
    --to=kumar.gala@freescale.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=trini@kernel.crashing.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).