Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Franck" <vagabon.xyz@gmail.com>
Cc: "Nigel Stephens" <nigel@mips.com>, <linux-mips@linux-mips.org>
Subject: Re: [RFC] Optimize swab operations on mips_r2 cpu
Date: Fri, 27 Jan 2006 13:53:58 +0100	[thread overview]
Message-ID: <001d01c62340$be267bb0$10eca8c0@grendel> (raw)
In-Reply-To: cda58cb80601270245g6273ce04k@mail.gmail.com

> > Configuration hacks that are specific to a single core create cruft and
> > maintenence problems.  As I said yesterday, I think we'd be much better
> > off to have a CONFIG_CPU_MIPS_SMALL or some such option
> > that could cause -Os to be used, allow branch-likelies, etc. The optimizations
> > under discussion aren't at all specific to the 4KSd,
> 
> no some are. As we said previously:
> 
>         1/ sizeof(vmlinux-mips32r2-Os) > sizeof(vmlinux-4ksd-Os)
>         2/ with -march=4ksd can do (slightly) better optimizations.

This is very possibly due to the compiler knowing about the SmartMIPS
scaled, indexed load instructions, which were added to improve virtual
machine performance, but which also save on address calculation instructions.
If -march=mips32r2 combined with -msmartmips and -Os don't produce
pretty much the same result as -march=4ksd, I'd be interested in knowing
why. Regardless, if this is what's going on, there really is no other core 
in production today that will run that code.  But that doesn't mean
that there won't be others in the future.

All I'm really trying to do here is to get away from core-specific config
cruft.  If the best result under-the-hood for 4KSd is obtained by using 
-march=4ksd, that's what people should get, but I'd rather that users
and maintainers saw that as a choice of MIPS32R2+SmartMIPS rather 
than a choice of 4KSd as a one-off.

        Regards,

        Kevin K.

WARNING: multiple messages have this Message-ID (diff)
From: "Kevin D. Kissell" <kevink@mips.com>
To: Franck <vagabon.xyz@gmail.com>
Cc: Nigel Stephens <nigel@mips.com>, linux-mips@linux-mips.org
Subject: Re: [RFC] Optimize swab operations on mips_r2 cpu
Date: Fri, 27 Jan 2006 13:53:58 +0100	[thread overview]
Message-ID: <001d01c62340$be267bb0$10eca8c0@grendel> (raw)
Message-ID: <20060127125358.r2tPskMbUnNmNXjav4ps5YJLqzJNlwQ3u9hHv6jsnBE@z> (raw)
In-Reply-To: cda58cb80601270245g6273ce04k@mail.gmail.com

> > Configuration hacks that are specific to a single core create cruft and
> > maintenence problems.  As I said yesterday, I think we'd be much better
> > off to have a CONFIG_CPU_MIPS_SMALL or some such option
> > that could cause -Os to be used, allow branch-likelies, etc. The optimizations
> > under discussion aren't at all specific to the 4KSd,
> 
> no some are. As we said previously:
> 
>         1/ sizeof(vmlinux-mips32r2-Os) > sizeof(vmlinux-4ksd-Os)
>         2/ with -march=4ksd can do (slightly) better optimizations.

This is very possibly due to the compiler knowing about the SmartMIPS
scaled, indexed load instructions, which were added to improve virtual
machine performance, but which also save on address calculation instructions.
If -march=mips32r2 combined with -msmartmips and -Os don't produce
pretty much the same result as -march=4ksd, I'd be interested in knowing
why. Regardless, if this is what's going on, there really is no other core 
in production today that will run that code.  But that doesn't mean
that there won't be others in the future.

All I'm really trying to do here is to get away from core-specific config
cruft.  If the best result under-the-hood for 4KSd is obtained by using 
-march=4ksd, that's what people should get, but I'd rather that users
and maintainers saw that as a choice of MIPS32R2+SmartMIPS rather 
than a choice of 4KSd as a one-off.

        Regards,

        Kevin K.

  parent reply	other threads:[~2006-01-27 12:47 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-25  9:36 [RFC] Optimize swab operations on mips_r2 cpu Franck
2006-01-25 12:47 ` Ralf Baechle
2006-01-25 13:34   ` Franck
2006-01-25 14:11     ` Kevin D. Kissell
2006-01-25 14:14       ` Ralf Baechle
2006-01-25 14:32         ` Franck
2006-01-25 15:04           ` Ralf Baechle
2006-01-25 18:03             ` Franck
2006-01-25 18:15               ` Kevin D. Kissell
2006-01-26  8:11                 ` Franck
2006-01-26  8:26                   ` Kevin D. Kissell
2006-01-26  8:47                     ` Franck
2006-01-26  9:17                       ` Kevin D. Kissell
2006-01-26  9:17                         ` Kevin D. Kissell
2006-01-26 11:56                         ` Franck
2006-01-26 15:02                 ` Franck
2006-01-26 15:23                   ` Kevin D. Kissell
2006-01-26 15:23                     ` Kevin D. Kissell
2006-01-26 15:29                     ` Franck
2006-01-26 15:51                     ` Nigel Stephens
2006-01-26 16:31                       ` Franck
2006-01-26 16:53                         ` Kevin D. Kissell
2006-01-26 16:53                           ` Kevin D. Kissell
2006-01-26 16:55                         ` Nigel Stephens
2006-01-26 18:02                           ` Franck
2006-01-26 20:25                             ` Nigel Stephens
2006-01-27  9:03                               ` Franck
2006-01-27 10:13                                 ` Kevin D. Kissell
2006-01-27 10:13                                   ` Kevin D. Kissell
2006-01-27 10:45                                   ` Franck
2006-01-27 11:31                                     ` Ralf Baechle
2006-01-27 12:53                                     ` Kevin D. Kissell [this message]
2006-01-27 12:53                                       ` Kevin D. Kissell
2006-01-27 14:44                                       ` Franck
2006-01-27 11:30                                   ` Ralf Baechle
2006-01-27 13:45                                 ` Nigel Stephens
2006-01-27 14:54                                   ` Franck
2006-01-27 15:04                                     ` Maciej W. Rozycki
2006-01-27 15:39                                     ` Kevin D. Kissell
2006-01-27 15:39                                       ` Kevin D. Kissell
2006-01-27 17:32                                       ` Franck
2006-01-29 15:07                                         ` Ralf Baechle
2006-01-30 13:08                                           ` Maciej W. Rozycki
2006-01-30 14:31                                           ` Franck

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='001d01c62340$be267bb0$10eca8c0@grendel' \
    --to=kevink@mips.com \
    --cc=linux-mips@linux-mips.org \
    --cc=nigel@mips.com \
    --cc=vagabon.xyz@gmail.com \
    /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