public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
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 


  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).