public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ira Rosen <IRAR@il.ibm.com>
To: Zdenek Dvorak <rakdver@kam.mff.cuni.cz>
Cc: dberlin@dberlin.org, Diego Novillo <dnovillo@google.com>,
	        Dorit Nuzman <DORIT@il.ibm.com>,
	dvorakz@suse.cz, gcc-patches@gnu.org
Subject: Re: [patch] Remove redundant calls to copy_virtual_operands
Date: Wed, 08 Aug 2007 11:04:00 -0000	[thread overview]
Message-ID: <OF6667480D.99240450-ONC2257331.003A1EA2-C2257331.003CB6C2@il.ibm.com> (raw)
In-Reply-To: <20070808094101.GA32541@kam.mff.cuni.cz>



Zdenek Dvorak <rakdver@kam.mff.cuni.cz> wrote on 08/08/2007 12:41:01:

> on the other hand, the fact that there are ICEs shows that there is some
> problem in setting the alias information for the new statements in
> vectorizer -- if this were correct, the virtual operands would be
> exactly the same as the ones of the original statement; so although I
> agree that leaving things to update_ssa is easier to maintain (although
> possibly much slower), it would be nice if someone could check what does
> the alias information updating code in vectorizer get wrong,

Currently the vectorizer both sets a memory tag and copies virtual
operands. Sometimes, like in the example below, the tag provided by the
vectorizer is more accurate than the alias information we had before, i.e.,
the virtual operands of the scalar memory operations (although I only have
a testcase for this on 4.1.1).

Here is the testcase (for gcc 4.1.1):

#define N 64

short AA[4096], BB[4096];

main()
{
  int j;

       for (j = 0; j < N; j++){
         *(AA+j) = 1.0;
         *(BB+j) = 1.0;
       }
}


After vectorization and copying vops from scalars we get:
 ...
  # BBD.1944_22 = PHI <BBD.1944_19(2), BBD.1944_14(4)>;
  # AAD.1943_21 = PHI <AAD.1943_18(2), AAD.1943_15(4)>;
<L0>:;
  ...
  #   AAD.1943_16 = V_MAY_DEF <AAD.1943_21>;
  #   BBD.1944_17 = V_MAY_DEF <BBD.1944_22>;
  *ivtmp.40D.2017_28 = vect_cst_.35D.2012_25;
  #   AAD.1943_18 = V_MAY_DEF <AAD.1943_16>;
  #   BBD.1944_19 = V_MAY_DEF <BBD.1944_17>;
  *ivtmp.46D.2024_33 = vect_cst_.41D.2019_30;
 ...

While the memtags the vectorizer sets distinguish between AA and BB.
Therefore, by both setting more accurate tags and copying less accurate
vops, we create an inconsistency.

The ICE we get on gcc 4.1.1 is that ivopts pass rewrites the memory
operations and calls update_stmt() to update vops based on the memtags set
by the vectorizer.
Here is what we get after ivopts pass:

  # BBD.1944_22 = PHI <BBD.1944_19(2), BBD.1944_14(0)>;
  # AAD.1943_21 = PHI <AAD.1943_18(2), AAD.1943_15(0)>;
<L0>:;
  ...
  #   AAD.1943_16 = V_MAY_DEF <AAD.1943_21>;
  MEM[base: &AAD.1943, index: D.2034_10]{*ivtmp.40D.2017} =
vect_cst_.35D.2012_25;
  ...
  #   BBD.1944_19 = V_MAY_DEF <BBD.1944_17>;
  MEM[base: &BBD.1944, index: D.2035_6]{*ivtmp.46D.2024} =
vect_cst_.41D.2019_30;
  ...

it removes V_MAY_DEF of BB when writing to AA and V_MAY_DEF of AA when
writing to BB. The problem is that the remaining defs are not updated and
verify_ssa fails (there is a use of BBD.1944_17 without a def).

Our assumption was that creating such an inconsistent information in the
vectorizer is incorrect. And that since by setting more accurate memtags we
improve the alias info, we should simply remove the calls to
copy_virtual_operands.

Thanks,
Ira

>
> Zdenek

  reply	other threads:[~2007-08-08 11:04 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-07 12:10 Ira Rosen
2007-08-07 13:06 ` Dorit Nuzman
2007-08-07 13:23   ` Diego Novillo
2007-08-08  8:02     ` Ira Rosen
2007-08-08 12:06       ` Diego Novillo
2007-08-08  9:41     ` Zdenek Dvorak
2007-08-08 11:04       ` Ira Rosen [this message]
2007-08-12 19:40         ` Zdenek Dvorak
2007-08-07 13:22 ` Diego Novillo

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=OF6667480D.99240450-ONC2257331.003A1EA2-C2257331.003CB6C2@il.ibm.com \
    --to=irar@il.ibm.com \
    --cc=DORIT@il.ibm.com \
    --cc=dberlin@dberlin.org \
    --cc=dnovillo@google.com \
    --cc=dvorakz@suse.cz \
    --cc=gcc-patches@gnu.org \
    --cc=rakdver@kam.mff.cuni.cz \
    /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).