public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Dorit Nuzman <DORIT@il.ibm.com>
To: Victor Kaplansky <VICTORK@il.ibm.com>
Cc: gcc-patches@gnu.org, rakdver@kam.mff.cuni.cz
Subject: Re: [PATCH] [4.3 projects] Verctorizer - versioning for alias
Date: Thu, 16 Aug 2007 13:09:00 -0000	[thread overview]
Message-ID: <OF531586B8.1BD86F22-ONC2257339.0046568C-C2257339.00487D11@il.ibm.com> (raw)
In-Reply-To: <OF9FE87E7A.5E31017F-ONC2257339.003A589C-C2257339.003CEC7A@il.ibm.com>

> Please find below updated patch after implementation of comments
> from Dorit and Zdenek.
>
>   Here is the list of changes from previous patch:
>   - A new testcase when IN and OUT overlap in such a way that
> the vectorized copy of the loop would produce wrong results if
> it were used added(vect-vfa-04.c).
>   - Fixed the size of segment accessed by data reference in cases
> when realignment loads are used.

Is there a testcase that catches this case?

>   - POINTER_PLUS_EXPR used insted of PLUS_EXPR for pointer
> arithmentics.
>   - Parameters "vect-max-version-for-alignment-checks" and
> "vect-max-version-for-alias-checks" documented in invoke.texi.

(make sure you pass make info/make dvi, if you haven't yet)

>   - Fixed typos and unclear comments.
>

So you're going to address the rest of the comments in a separate patch
(cost-model updates, improved handling of interleaved-accesses, adding
testcases that combine interleaving and versioning-for-aliasing, factoring
out the versioning related stuff from vect_transform_loop)? (that would be
fine with me, just want to make sure you're planning to address these
issues too).

>
> Bootstrapped with vectorization enabled on x86_64, regtested on
> x86_64.
> Okay for mainline after boostrap and regression testing on PPC?
>
>
>
> 2007-08-14  Victor Kaplansky <victork@il.ibm.com>
>
> ChangeLog:
>
...
>              (vect_enhance_data_refs_alignment): Define local variable
>              vect_versioning_for_alias_required, don't perform
>              versioning for alignment if versioning for alias is
>              required.

so I asked this before: I think you mean "don't perform **peeling** for
alignment if versioning for alias is required", right?

Lastly, about:

+static tree
+vect_vfa_segment_size (struct data_reference *dr, tree vect_factor)
+{
+  tree segment_length;
+
+  if (vect_supportable_dr_alignment (dr) ==
dr_unaligned_software_pipeline)
+    {
+      tree vector_size =
+        build_int_cst (integer_type_node,
+          GET_MODE_SIZE (TYPE_MODE (STMT_VINFO_VECTYPE

I think you can use TYPE_VECTOR_SUBPARTS() instead of
GET_MODE_SIZE (TYPE_MODE ()) (just a tiny bit more compact)

Also, for more compact code, you could compute the vf*step once and reuse
it for both then and else. For your consideration.

+         (vinfo_for_stmt (DR_STMT (dr))))));
+
+      segment_length =
+     fold_convert (sizetype,
+       fold_build2 (PLUS_EXPR, integer_type_node,
+         fold_build2 (MULT_EXPR, integer_type_node, DR_STEP (dr),
+                  vect_factor),
+         vector_size));
+
+
+    }
+  else
+    {
+      segment_length =
+     fold_convert (sizetype,
+       fold_build2 (MULT_EXPR, integer_type_node, DR_STEP (dr),
+                  vect_factor));
+    }
+
+    return segment_length;
+}

OK otherwise,

thanks,
dorit

> (See attached file: vfa-n.txt)
> [attachment "vfa-n.txt" deleted by Dorit Nuzman/Haifa/IBM]

  reply	other threads:[~2007-08-16 13:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <OF128D770D.7C095078-ONC2257337.00562B23-C2257337.005E3D6E@LocalDomain>
2007-08-16 11:07 ` Victor Kaplansky
2007-08-16 13:09   ` Dorit Nuzman [this message]
     [not found] <OFD8F5F2C8.37DFE3DF-ONC2257339.004A59E3-C2257339.004BD2B1@LocalDomain>
2007-08-18  7:54 ` Dorit Nuzman
2007-08-19  9:20 ` Dorit Nuzman
2007-08-19 15:13 ` Dorit Nuzman
     [not found] <OF531586B8.1BD86F22-ONC2257339.0046568C-C2257339.00487D11@LocalDomain>
2007-08-16 13:49 ` Victor Kaplansky
2007-08-14 11:02 Victor Kaplansky
2007-08-14 11:38 ` Zdenek Dvorak
2007-08-14 12:23   ` Victor Kaplansky
2007-08-14 17:07 ` Dorit Nuzman

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=OF531586B8.1BD86F22-ONC2257339.0046568C-C2257339.00487D11@il.ibm.com \
    --to=dorit@il.ibm.com \
    --cc=VICTORK@il.ibm.com \
    --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).