public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <jh@suse.cz>
To: Michael Matz <matzmich@cs.tu-berlin.de>
Cc: Bernd Schmidt <bernds@redhat.com>, gcc@gcc.gnu.org
Subject: Re: long long / long long
Date: Tue, 11 Sep 2001 02:26:00 -0000	[thread overview]
Message-ID: <20010911112552.I22028@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <Pine.GSO.4.33.0109102134450.29271-100000@platon>

> Hi,
> 
> On Mon, 10 Sep 2001, Bernd Schmidt wrote:
> > > Well, the Linux kernel developers found that they couldn't let gcc
> > > do long long arithmetic because it did such a poor job, so they do
> > > it in assembly or in C on pairs of 32 bit values instead.  So at
> > > least some folks probably wouldn't mind seeing an improvement.
> >
> > The main problem probably is the register allocator's requirement that
> > DImode values be allocated to adjacent registers.
> 
> Yes, that requirement creates many constraints.
> 
> > Unfortunately this is not going to be easy to change.
> 
> The sad thing is, that it _is_ easy to change in the allocator, and in
> fact would make the algorithm simpler (I'm talking only about the
> new-regalloc) and the graph easier colorable.  The thing which horrifies
> me is the encoding of that requirement in the different machine
> descriptions.  A first step would be to define a new rtx code MREG
> ("multi" reg), which can possibly contain a set of (disjoint) REG
We sometimes represent such MREG as PARALLELs of multiple REGS, we also do have
CONCAT expression.  I think these should be used to represent register pairs
too.

All you need is to teach register_operand and simplify_subreg about it.  Then
to fix all those zillions of side effects the change will have (not so extremly
many I can think of - the flow analyzis and register renaming probably,
scheduler should be happy).  But having this as option controlable by target
macro (note that on i386, the 64bit multiply instruction requires the registers
in order), it can be trackable.  We will just convert those machine descriptions
where it makes sense.  There are still many, where the pairs must be consetuctive,
as hardware dictates that.

Honza
> or SUBREG expressions, including the then necessary handling of multi-reg
> moves (with cycle breaking).  The occurences of those MREG rtx's could
> probably be limited to few passes around the allocator.  Unfortunately
> nevertheless all .md files would need a good overhaul.  If we only had
> such a multi-reg rtx from the beginning ;-|
> 
> 
> Ciao,
> Michael.

  parent reply	other threads:[~2001-09-11  2:26 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-08  8:31 Multiplications on Pentium 4 dewar
2001-09-08  9:17 ` Jan Hubicka
2001-09-08 17:13   ` Profiling and optimization Frank Klemm
2001-09-08 19:08   ` long long / long long Frank Klemm
2001-09-09 21:53     ` Joe Buck
2001-09-09 22:21       ` John S. Dyson
2001-09-10  6:20       ` Bernd Schmidt
2001-09-10 12:47         ` Michael Matz
2001-09-10 19:55           ` Hans-Peter Nilsson
2001-09-11  2:26           ` Jan Hubicka [this message]
2001-09-10 10:21       ` Linus Torvalds
2001-09-10 10:40         ` David Edelsohn
2001-09-11  2:21           ` Jan Hubicka
2001-09-11  2:20         ` Jan Hubicka
2001-09-11  8:06           ` Linus Torvalds
2001-09-10 12:18       ` Florian Weimer
2001-09-10 10:48 mike stump
2001-09-11  5:06 Benedetto Proietti

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=20010911112552.I22028@atrey.karlin.mff.cuni.cz \
    --to=jh@suse.cz \
    --cc=bernds@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=matzmich@cs.tu-berlin.de \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).