From: Mircea Namolaru <NAMOLARU@il.ibm.com>
To: Joern Rennecke <joern.rennecke@superh.com>
Cc: gcc@gcc.gnu.org, joern.rennecke@superh.com (Joern Rennecke),
Leehod Baruch <LEEHOD@il.ibm.com> (Leehod Baruch)
Subject: Re: Exploiting dual mode operation
Date: Mon, 26 Apr 2004 16:41:00 -0000 [thread overview]
Message-ID: <OFF716A77D.9A877FB6-ONC2256E82.002B083C-42256E82.003FEB38@il.ibm.com> (raw)
In-Reply-To: <200404221428.i3MES0q32605@linsvr1.uk.superh.com>
Hello,
1. Trying to solve the sign extension removal problem using the live
highpart
information has some limitations. For instance in the following case
(which
appears during computation of array addresses):
i = sign extension i1;
....
index = 64-bit shift of i // the target and the source are 64 bits
In some architectures we may get the same result without using an explicit
sign
extension. As we understand it, your algorithm will found that the
highpart of
"i" is live and the sign extension will not be discarded.
Another example is:
int i, s;
for (i = 0; i < N; i++)
{
s1 = s + i;
s = sign extend s1;
}
return s;
The sign extension is required for the return only, so the sign extension
can be
removed from the loop and placed before the return. The highpart of "s" is
live,
but this information alone will not help to improve the code.
2. To exploit the dual mode operation, for instructions that uses the
result of
explicit sign extensions we need to found if it is possible to get the
same result
via an instruction that doesn't require explicit sign extensions.
Basically we
need to found if:
s1 = sign extend s
t1 = sign extend t
result = inst s1, t1
can be replaced by an instruction inst1:
result = inst1 s, t.
But this seems similar with what combine does, so the information
from the description file should suffice.
3. One possible way for implementation is to use reaching definitions
to propagate the sign extensions forward right before the uses. This will
create
opportunities for combine and gcse to do the rest of the work afterward.
Another possible way is to extend gcse (but there are some issues that
we still need to clarify).
Maybe there is a way to use your code (or part of it) ?
Mircea and Leehod
next prev parent reply other threads:[~2004-04-26 10:33 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
2004-04-26 16:41 ` Mircea Namolaru [this message]
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=OFF716A77D.9A877FB6-ONC2256E82.002B083C-42256E82.003FEB38@il.ibm.com \
--to=namolaru@il.ibm.com \
--cc=LEEHOD@il.ibm.com \
--cc=gcc@gcc.gnu.org \
--cc=joern.rennecke@superh.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).