public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrew MacLeod <amacleod@redhat.com>
To: Diego Novillo <dnovillo@redhat.com>
Cc: gcc mailing list <gcc@gcc.gnu.org>
Subject: Re: [tree-ssa] Out of SSA status and issues
Date: Mon, 12 May 2003 15:57:00 -0000	[thread overview]
Message-ID: <1052755028.2743.368.camel@p4> (raw)
In-Reply-To: <20030512153811.GA32572@tornado.toronto.redhat.com>

On Mon, 2003-05-12 at 11:38, Diego Novillo wrote:
> On Mon, May 12, 2003 at 10:42:43AM -0400, Andrew MacLeod wrote:
> 
> > So this problem needs to be resolved before we can turn on overlapping
> > ranges. We must not propagate copies which are going to cause conflicts
> > with other registers that are used across abnormal critical edges.  
> > 
> Perhaps we could just teach copy-prop not to use critical edges
> for the time being.  Or, to avoid pessimizing too much, we could
> try and use the same check we have now for overlapping live
> ranges in the SSA renamer.  I'm not sure if it's feasible,
> though.
> 

Unfortunately, it not propagating over a critical edge thats the
problem. Its propagating a copy past another use to form an overlapping
live range where both of those values are used in a PHI node at some
point across abnormal critical edges.

I beleive the bvrute force approach is to flag any variables which are
elements of PHI's acroiss an abnormal ciroitcal edge, and never copy
propagate them  ie, so in the example, when you look at the PHI, you see
p_9 and p_14 are used across abnormal critical edges, so you stick them
in a list of variables never to copy propagate.

I dont know that another optimiation might not do something which
results in the same condition or not. Time will tell.

On another note, shouldn't the into-ssa-pass's copy propagation only be
turned on when -ftree-copyprop is specified?  I think we do it all the
time right now... thus my problem in libstdc++ even without
-ftree-copyprop...


> We can't just unshare the INDIRECT_REF nodes.  The solution needs
> to share all the nodes that have the same pointer (i.e., all the
> (*p_3)_n SSA names need to have the same variable *p_3 as their
> SSA_NAME_VAR).  Once I fix that, it should all just work (FLW).
> 

Thats the working theory anwyay :-)

Andrew

  reply	other threads:[~2003-05-12 15:57 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-12 14:42 Andrew MacLeod
2003-05-12 15:38 ` Diego Novillo
2003-05-12 15:57   ` Andrew MacLeod [this message]
2003-05-12 16:05     ` Michael Matz
2003-05-12 16:10       ` Andrew MacLeod
2003-05-12 16:16       ` law
2003-05-12 17:08     ` law
2003-05-12 17:12       ` Andrew MacLeod
2003-05-12 17:26         ` law
2003-05-12 18:57 ` Andrew MacLeod
2003-05-13  9:07   ` Michael Matz
2003-05-13 12:42     ` Diego Novillo
2003-05-13 12:50       ` Andrew MacLeod
2003-05-13 13:05         ` Diego Novillo
2003-05-13 13:29           ` Andrew MacLeod
2003-05-13 13:57             ` Diego Novillo
2003-05-13 12:57       ` Michael Matz
2003-05-13 13:11         ` Diego Novillo
2003-05-13 13:18           ` Andrew MacLeod
2003-05-14 17:19             ` Jan Vroonhof
2003-05-14 18:05               ` Andrew MacLeod
2003-05-14 18:33               ` Diego Novillo
2003-05-14 19:11                 ` Daniel Berlin
2003-05-13 15:01         ` Daniel Berlin
2003-05-13 12:33   ` Diego Novillo
2003-05-13 12:49     ` Andrew MacLeod
2003-05-13 12:58       ` Diego Novillo
2003-05-13 13:17 Richard Kenner
2003-05-13 13:27 ` Diego Novillo
2003-05-13 13:40 ` Michael Matz
2003-05-13 15:08 ` Michael S. Zick
2003-05-13 13:42 Richard Kenner
2003-05-13 15:23 Richard Kenner
2003-05-13 18:50 ` Geoff Keating
2003-05-13 23:28   ` Michael S. Zick
2003-05-17 17:19 ` Michael S. Zick

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=1052755028.2743.368.camel@p4 \
    --to=amacleod@redhat.com \
    --cc=dnovillo@redhat.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).