On Tue, 29 Oct 2019, Andre Vieira (lists) wrote:
> Hi richi,
>
>
> Committed the patch with the suggested change in revision r277569.
>
> I will look at the follow-up, from what I understood the idea was to add a
> field to the dr_vec_info where we keep the "extra-offset" that represents the
>
m 3aba91fb4d1a0dcfa04b8c8ead1941679cd46ae3 Mon Sep 17 00:00:00 2001
From: Andre Simoes Dias Vieira
Date: Fri, 18 Oct 2019 17:49:58 +0100
Subject: [PATCH 2/3] [PATCH 1/2][vect]PR 88915: Vectorize epilogues when
versioning loops
---
gcc/tree-ssa-loop-niter.c
On Mon, 28 Oct 2019, Andre Vieira (lists) wrote:
> Hi,
>
> Reworked according to your comments, see inline for clarification.
>
> Is this OK for trunk?
+ gimple_seq seq = STMT_VINFO_PATTERN_DEF_SEQ (stmt_vinfo);
+ while (seq)
+ {
+ stmt_work
Hi,
Reworked according to your comments, see inline for clarification.
Is this OK for trunk?
gcc/ChangeLog:
2019-10-28 Andre Vieira
PR 88915
* tree-ssa-loop-niter.h (simplify_replace_tree): Change declaration.
* tree-ssa-loop-niter.c (simplify_replace_tree): Add context paramete
On Fri, 25 Oct 2019, Andre Vieira (lists) wrote:
> Hi,
>
> This is the reworked patch after your comments.
>
> I have moved the epilogue check into the analysis form disguised under
> '!epilogue_vinfos.is_empty ()'. This because I realized that I am doing the
> "lowest threshold" check there.
>
On Fri, 25 Oct 2019, Andre Vieira (lists) wrote:
>
>
> On 22/10/2019 14:56, Richard Biener wrote:
> > On Tue, 22 Oct 2019, Andre Vieira (lists) wrote:
> >
> >> Hi Richi,
> >>
> >> See inline responses to your comments.
> >>
> >> On 11/10/2019 13:57, Richard Biener wrote:
> >>> On Thu, 10 Oct 20
Hi,
This is the reworked patch after your comments.
I have moved the epilogue check into the analysis form disguised under
'!epilogue_vinfos.is_empty ()'. This because I realized that I am doing
the "lowest threshold" check there.
The only place where we may reject an epilogue_vinfo is when
On 22/10/2019 14:56, Richard Biener wrote:
On Tue, 22 Oct 2019, Andre Vieira (lists) wrote:
Hi Richi,
See inline responses to your comments.
On 11/10/2019 13:57, Richard Biener wrote:
On Thu, 10 Oct 2019, Andre Vieira (lists) wrote:
Hi,
+
+ /* Keep track of vector sizes we know we
On 22/10/2019 18:52, Richard Sandiford wrote:
Thanks for doing this. Hope this message doesn't cover too much old
ground or duplicate too much...
"Andre Vieira (lists)" writes:
@@ -2466,15 +2476,65 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree niters,
tree nitersm1,
else
ni
Thanks for doing this. Hope this message doesn't cover too much old
ground or duplicate too much...
"Andre Vieira (lists)" writes:
> @@ -2466,15 +2476,65 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree
> niters, tree nitersm1,
>else
> niters_prolog = build_int_cst (type, 0);
>
> +
On Tue, 22 Oct 2019, Andre Vieira (lists) wrote:
> Hi Richi,
>
> See inline responses to your comments.
>
> On 11/10/2019 13:57, Richard Biener wrote:
> > On Thu, 10 Oct 2019, Andre Vieira (lists) wrote:
> >
> >> Hi,
> >>
>
> >
> > +
> > + /* Keep track of vector sizes we know we can vectori
Hi Richi,
See inline responses to your comments.
On 11/10/2019 13:57, Richard Biener wrote:
On Thu, 10 Oct 2019, Andre Vieira (lists) wrote:
Hi,
+
+ /* Keep track of vector sizes we know we can vectorize the epilogue
with. */
+ vector_sizes epilogue_vsizes;
};
please don't enlarge
On Thu, 10 Oct 2019, Andre Vieira (lists) wrote:
> Hi,
>
> After all the discussions and respins I now believe this patch is close to
> what we envisioned.
>
> This patch achieves two things when vect-epilogues-nomask=1:
> 1) It analyzes the original loop for each supported vector size and saves
Hi,
After all the discussions and respins I now believe this patch is close
to what we envisioned.
This patch achieves two things when vect-epilogues-nomask=1:
1) It analyzes the original loop for each supported vector size and
saves this analysis per loop, as well as the vector sizes we know
On Tue, 8 Oct 2019, Andre Vieira (lists) wrote:
> Hi Richard,
>
> As I mentioned in the IRC channel, I managed to get "most" of the regression
> testsuite working for x86_64 (avx512) and aarch64.
>
> On x86_64 I get a failure that I can't explain, was hoping you might be able
> to have a look wi
Hi Richard,
As I mentioned in the IRC channel, I managed to get "most" of the
regression testsuite working for x86_64 (avx512) and aarch64.
On x86_64 I get a failure that I can't explain, was hoping you might be
able to have a look with me:
"PASS->FAIL: gcc.target/i386/vect-perm-odd-1.c exec
Hi Richard,
As I mentioned in the IRC channel, this is my current work in progress
patch. It currently ICE's when vectorizing
gcc/testsuite/gcc.c-torture/execute/nestfunc-2.c with '-O3' and '--param
vect-epilogues-nomask=1'.
It ICE's because the epilogue loop (after if conversion) and main l
On 8/23/19 10:50 AM, Andre Vieira (lists) wrote:
> Hi,
>
> This patch is an improvement on my last RFC. As you pointed out, we can
> do the vectorization analysis of the epilogues before doing the
> transformation, using the same approach as used by openmp simd. I have
> not yet incorporated the
On Fri, 23 Aug 2019, Andre Vieira (lists) wrote:
> Hi,
>
> This patch is an improvement on my last RFC. As you pointed out, we can do
> the vectorization analysis of the epilogues before doing the transformation,
> using the same approach as used by openmp simd. I have not yet incorporated
> th
Hi,
This patch is an improvement on my last RFC. As you pointed out, we can
do the vectorization analysis of the epilogues before doing the
transformation, using the same approach as used by openmp simd. I have
not yet incorporated the cost tweaks for vectorizing the epilogue, I
would like
20 matches
Mail list logo
