public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jim Wilson <wilson@cygnus.com>
To: egcs@cygnus.com
Cc: Torbjorn Granlund <tege@pdc.kth.se>,
	law@cygnus.com, "David S. Miller" <davem@jenolan.rutgers.edu>
Subject: Re: This was fun to track down
Date: Wed, 24 Sep 1997 12:58:00 -0000	[thread overview]
Message-ID: <199709241957.MAA01872@cygnus.com> (raw)
In-Reply-To: <20478.875066879@hurl.cygnus.com>

	  > 2. If convert_modes is really right, the proper fix to expand_divmod
	  >    would be to avoid calling it when op1 is constant.
	I don't think you can just avoid the call -- you can't just
	operate on constants without any regard to their size.

Gcc has two different kinds of conversion routines.

There are routines that convert RTL to RTL, and which will never emit insns.
This includes gen_lowpart and operand_subword.

There are routines that emit the insns that are required if any to convert
one RTL to another RTL.  This includes convert_modes.

These two different kinds of conversion routines are often confused.
The former is equivalent to converting a int to a float via a union, and
the later is equivalent to converting a int to a float via a cast.

I see no reason why expand_divmod needs to call convert_modes in this case.
If we are passed in a constant value, then we should keep the value as a
constant, so that we have a chance of emitting optimized code for the divide.
There is no need to emit insns to perform an actual conversion on the value.
All we need to do is convert the RTL itself, and I don't even think that is
necessary, since a CONST_INT is valid regardless of the mode.

Hence, it looks like expmed.c should be calling gen_lowpart (or something
similar) instead of convert_modes if op1 is a constant.  This will give
better code than the current patch by retaining the constant.

Jim

  reply	other threads:[~1997-09-24 12:58 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-09-22 19:37 David S. Miller
1997-09-23  0:25 ` Jeffrey A Law
1997-09-23  1:49 ` Torbjorn Granlund
1997-09-23 14:09   ` David S. Miller
1997-09-23 13:41 ` Torbjorn Granlund
1997-09-23 13:50   ` David S. Miller
1997-09-23 13:57     ` Torbjorn Granlund
1997-09-23 14:16       ` David S. Miller
1997-09-23 19:05       ` Jeffrey A Law
1997-09-24 12:58         ` Jim Wilson [this message]
1997-09-24 23:15           ` Jeffrey A Law
1997-09-27 13:40             ` Torbjorn Granlund
1997-09-27 23:38               ` Jeffrey A Law
1997-09-29 11:53               ` Jim Wilson

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=199709241957.MAA01872@cygnus.com \
    --to=wilson@cygnus.com \
    --cc=davem@jenolan.rutgers.edu \
    --cc=egcs@cygnus.com \
    --cc=law@cygnus.com \
    --cc=tege@pdc.kth.se \
    /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).