public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Tom de Vries <tom@codesourcery.com>
To: Paolo Bonzini <bonzini@gnu.org>
Cc: Eric Botcazou <ebotcazou@adacore.com>,
	gcc-patches@gcc.gnu.org,  Bernd Schmidt <bernds@codesourcery.com>
Subject: Re: new sign/zero extension elimination pass
Date: Sun, 31 Oct 2010 19:30:00 -0000	[thread overview]
Message-ID: <4CCDAD7E.9040005@codesourcery.com> (raw)
In-Reply-To: <4CC9E8AB.90206@gnu.org>

Paolo Bonzini wrote:
> On 10/28/2010 08:46 PM, Tom de Vries wrote:
>> The best version I can think now of is an iterative solution using
>> DU/UD-chains,
>> like this:
>> - Calculate and store the size of each use.
>> - Calculate and store the biggest use of each def (using DU-chains).
>> - Push the progating defs where the biggest use size is smaller than
>> word size
>>    on a stack.
>> - Pop a def.
>> - For the def, check if the propagated biggest use is bigger than the
>> current
>>    biggest use.
>>    If not, back to pop a def.
>>    If so, store current biggest use as propagated biggest use.
>> - For the def, propagate the biggest use of the def to the operands.
>> - For each operand, if the use size was reduced, find the reaching
>> definitions
>>    (using UD-chains).
>> - For each propagating definition, recompute the biggest use. If that
>> one was
>>    reduced below the propagated biggest use, push the def on the stack.
>> - back to pop a def.
>>
> 
> DU and UD-chains are quadratic, and the reaching definitions problem has
> very big solutions too, so they are rarely the right solution
> (unfortunately).
> 

thanks, I overlooked that completely.

> In addition, I wonder if this pass wouldn't introduce new undefined
> overflows, which would be a correctness problem.

The pass assumes wraparound overflow for plus and minus. The documentation of
the rtl operator 'plus' states that 'plus wraps round modulo the width of m'
(similar for 'minus'). I interpreted this independently from -fwrapv and
-fstrict-overflow, am I wrong there?

>  If you're going for a
> rewrite, I'd do it on tree-SSA so that:
> 
> 1) you can use unsigned math to avoid undefined overflow;
> 
> 2) SSA will provide you with cheap DU/UD.
> 
> Hopefully, only simple redundancies will remain after expand, and fwprop
> can take care of these using Andrew's patch.
> 

I see your point about the cheap DU/UD. I think the answer whether to do it in
tree-SSA or RTL depends on the answer to my previous question. If going to
tree-SSA allows us to catch more cases, we should do that.

- Tom

  parent reply	other threads:[~2010-10-31 17:55 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-18 15:54 Tom de Vries
2010-10-18 16:03 ` Andrew Pinski
2010-10-18 16:59   ` Richard Guenther
2010-10-21 10:06     ` Tom de Vries
2010-10-21 10:44   ` Paolo Bonzini
2010-10-21 11:00     ` Paolo Bonzini
2010-10-21 17:21     ` Paolo Bonzini
2010-10-22  9:05       ` Tom de Vries
2010-10-22  9:24         ` Paolo Bonzini
2010-10-22  9:15 ` Eric Botcazou
2010-10-28 20:45   ` Tom de Vries
2010-10-29  2:11     ` Paolo Bonzini
2010-10-29  2:42       ` Paolo Bonzini
2010-10-31 19:30       ` Tom de Vries [this message]
2010-10-31 20:58         ` Joseph S. Myers
2010-10-31 21:11         ` Paolo Bonzini
2010-11-03 18:49           ` Eric Botcazou
2010-10-29  1:04   ` Paolo Bonzini
2010-10-29  1:33     ` Paolo Bonzini
2010-11-03 18:50     ` Eric Botcazou
2010-11-08 21:29     ` Tom de Vries
2010-11-08 22:11       ` Paolo Bonzini
2010-11-12  8:29         ` Tom de Vries
2010-11-13 10:41           ` Eric Botcazou
2012-07-11 10:31             ` Tom de Vries
2012-07-11 11:42               ` Jakub Jelinek
2012-07-11 13:01                 ` Tom de Vries
2012-07-12  1:52               ` Kenneth Zadeck
     [not found]               ` <4FFE2ADF.2060806@naturalbridge.com>
     [not found]                 ` <4FFE9346.2070806@mentor.com>
2012-07-12  9:21                   ` Tom de Vries
2012-07-12 12:05                     ` Kenneth Zadeck
2012-07-13  7:54                       ` Tom de Vries
2012-07-13 11:39                         ` Kenneth Zadeck
2012-07-13 12:58                           ` Tom de Vries
2012-07-17 15:17                         ` Kenneth Zadeck
2012-07-20 18:41                           ` Tom de Vries
2012-08-20 13:40               ` Tom de Vries
2010-10-28 20:55 ` Andrew Pinski
2010-10-28 21:00   ` Andrew Pinski
2010-10-28 21:12     ` Tom de Vries
2010-10-28 22:58       ` Andrew Pinski
2010-10-29 15:06         ` Tom de Vries
2010-10-29  0:34     ` Paolo Bonzini
2010-11-08 21:32 ` Andrew Pinski

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=4CCDAD7E.9040005@codesourcery.com \
    --to=tom@codesourcery.com \
    --cc=bernds@codesourcery.com \
    --cc=bonzini@gnu.org \
    --cc=ebotcazou@adacore.com \
    --cc=gcc-patches@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).