public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Joern Rennecke <joern.rennecke@superh.com>
To: LEEHOD@il.ibm.com (Leehod Baruch)
Cc: joern.rennecke@superh.com (Joern Rennecke),
	gcc@gcc.gnu.org, NAMOLARU@il.ibm.com (Mircea Namolaru)
Subject: Re: Exploiting dual mode operation
Date: Thu, 22 Apr 2004 14:59:00 -0000	[thread overview]
Message-ID: <200404221428.i3MES0q32605@linsvr1.uk.superh.com> (raw)
In-Reply-To: <OF07C3F3C0.3AF4AD56-ONC2256E7E.004A413F-C2256E7E.004A7BE1@il.ibm.com> from "Leehod Baruch" at Apr 22, 2004 04:33:45

> We see redundant sign extension removal as a partial 
> redundancy problem. This will give us not only the redundant 
> sign extensions, but also better placement for the 
> remaining ones. As a result sign extension instructions 
> may be moved and instructions that uses the highpart
> may be replaced with others that doesn't use it.

Why would you be using the highpart if you don't need to in the
first place?

Or are you saying that the port will have to duplicate patterns
that manipulate the highpart, to have a variant that uses and sets
only a smaller SUBREG, so that you can avoid tracking the lifeness
of the highpart separately?  That would be much more intrusive than
adding an attribute.

> This is not equivalent with live information for the highest 
> part of the registers. 
> 
> Our approach will not require changes in the description file 
> (which in our opinion is a major problem with your code) and will 
> limit the changes to much fewer files.

Without a special attribute in the machine description, or new code
that analyzes the md rtl to automatically generate this information,
you will have only scant information to feed into PRE computations.

And when you fix this problem, you will find that you need low-level
rtl to feed this pass, and then you don't want to push up the register
pressure with PRE.

  reply	other threads:[~2004-04-22 14:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-22 13:58 Leehod Baruch
2004-04-22 14:59 ` Joern Rennecke [this message]
2004-04-26 16:41   ` Mircea Namolaru
2004-04-26 16:57     ` Joern Rennecke
2004-04-29 14:26       ` Mircea Namolaru
  -- strict thread matches above, loose matches on Subject: below --
2004-06-07 17:17 Mircea Namolaru
2004-04-21 14:33 Mircea Namolaru
2004-04-21 18:42 ` Joern Rennecke

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=200404221428.i3MES0q32605@linsvr1.uk.superh.com \
    --to=joern.rennecke@superh.com \
    --cc=LEEHOD@il.ibm.com \
    --cc=NAMOLARU@il.ibm.com \
    --cc=gcc@gcc.gnu.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 read-only IMAP folder(s) and NNTP newsgroup(s).