On 18/06/20 16:25 +0200, Martin Liška wrote:
On 6/18/20 11:43 AM, Jonathan Wakely wrote:
On 18/06/20 00:55 +0100, Jonathan Wakely wrote:
Does your reverse iterator work correctly? It looks to me like it will
fail to visit the region_begin statement, because this loop will
terminate when the rev
On 6/18/20 11:43 AM, Jonathan Wakely wrote:
On 18/06/20 00:55 +0100, Jonathan Wakely wrote:
Does your reverse iterator work correctly? It looks to me like it will
fail to visit the region_begin statement, because this loop will
terminate when the reverse iterator reaches the end() value, and wil
On 18/06/20 00:55 +0100, Jonathan Wakely wrote:
Does your reverse iterator work correctly? It looks to me like it will
fail to visit the region_begin statement, because this loop will
terminate when the reverse iterator reaches the end() value, and will
not actually process that gsi:
- gimp
On 18/06/20 07:34 +0100, Richard Sandiford wrote:
Thanks for the comments, just had a question about one of them…
Jonathan Wakely writes:
On 16/06/20 15:14 +0100, Richard Sandiford wrote:
Martin Li?ka writes:
On 6/16/20 10:50 AM, Richard Sandiford wrote:
Hmm, sounds like a nice abstraction
Thanks for the comments, just had a question about one of them…
Jonathan Wakely writes:
> On 16/06/20 15:14 +0100, Richard Sandiford wrote:
>>Martin Li?ka writes:
>>> On 6/16/20 10:50 AM, Richard Sandiford wrote:
>>> Hmm, sounds like a nice abstraction but I see 2 problems with that:
>>>
>>> 1)
On 18/06/20 00:59 +0100, Jonathan Wakely wrote:
On 18/06/20 00:55 +0100, Jonathan Wakely wrote:
On 16/06/20 15:14 +0100, Richard Sandiford wrote:
Martin Li?ka writes:
On 6/16/20 10:50 AM, Richard Sandiford wrote:
Hmm, sounds like a nice abstraction but I see 2 problems with that:
1) How can
On 18/06/20 00:55 +0100, Jonathan Wakely wrote:
On 16/06/20 15:14 +0100, Richard Sandiford wrote:
Martin Li?ka writes:
On 6/16/20 10:50 AM, Richard Sandiford wrote:
Hmm, sounds like a nice abstraction but I see 2 problems with that:
1) How can I define a constructor of the iterator_pair when
On 16/06/20 15:14 +0100, Richard Sandiford wrote:
Martin Li?ka writes:
On 6/16/20 10:50 AM, Richard Sandiford wrote:
Hmm, sounds like a nice abstraction but I see 2 problems with that:
1) How can I define a constructor of the iterator_pair when I need something
like:
iterator_pair (region_beg
(Sorry, sent my previous message before seeing this one.)
Martin Sebor writes:
> Since the iterator_pair template is being added as a foundational
> type I'd suggest fleshing out the design a bit more. There is
> little difference between iterator_pair and std::pair, but since
> the class is bei
Martin Liška writes:
> On 6/16/20 4:14 PM, Richard Sandiford wrote:
>> Martin Liška writes:
>>> Hmm, sounds like a nice abstraction but I see 2 problems with that:
>>>
>>> 1) How can I define a constructor of the iterator_pair when I need
>>> something like:
>>> iterator_pair (region_begin, regi
On 6/17/20 11:05 AM, Martin Liška wrote:
On 6/16/20 4:14 PM, Richard Sandiford wrote:
Martin Liška writes:
On 6/16/20 10:50 AM, Richard Sandiford wrote:
Martin Liška writes:
Also, one minor formatting nit, sorry: the other functions instead
indent the “{” block by the same amount as the fun
On 6/16/20 4:14 PM, Richard Sandiford wrote:
Martin Liška writes:
On 6/16/20 10:50 AM, Richard Sandiford wrote:
Martin Liška writes:
Also, one minor formatting nit, sorry: the other functions instead
indent the “{” block by the same amount as the function prototype,
which seems more consiste
Martin Liška writes:
> On 6/16/20 10:50 AM, Richard Sandiford wrote:
>> Martin Liška writes:
Also, one minor formatting nit, sorry: the other functions instead
indent the “{” block by the same amount as the function prototype,
which seems more consistent with the usual out-of-class
On 6/16/20 10:50 AM, Richard Sandiford wrote:
Martin Liška writes:
Also, one minor formatting nit, sorry: the other functions instead
indent the “{” block by the same amount as the function prototype,
which seems more consistent with the usual out-of-class formatting.
Hope I fixed that.
Sor
Martin Liška writes:
> > Also, one minor formatting nit, sorry: the other functions instead
> > indent the “{” block by the same amount as the function prototype,
> > which seems more consistent with the usual out-of-class formatting.
>
> Hope I fixed that.
Sorry, I meant the other functions were
On 6/12/20 5:49 PM, Richard Sandiford wrote:
Martin Liška writes:
On 6/12/20 3:22 PM, Richard Sandiford wrote:
Martin Liška writes:
diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-patterns.c
index 636ad59c001..eac372e6abc 100644
--- a/gcc/tree-vect-patterns.c
+++ b/gcc/tree-vect-patter
On 6/12/20 11:49 AM, Richard Sandiford wrote:
Martin Liška writes:
On 6/12/20 3:22 PM, Richard Sandiford wrote:
Martin Liška writes:
diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-patterns.c
index 636ad59c001..eac372e6abc 100644
--- a/gcc/tree-vect-patterns.c
+++ b/gcc/tree-vect-pa
Martin Liška writes:
> On 6/12/20 3:22 PM, Richard Sandiford wrote:
>> Martin Liška writes:
>>> diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-patterns.c
>>> index 636ad59c001..eac372e6abc 100644
>>> --- a/gcc/tree-vect-patterns.c
>>> +++ b/gcc/tree-vect-patterns.c
>>> @@ -5120,20 +5120,12
On June 12, 2020 5:29:40 PM GMT+02:00, "Martin Liška" wrote:
>On 6/12/20 3:02 PM, Richard Biener wrote:
>> For(gimple. *stmt : bb_vinfo->region_stmts())
>
>Hm, that will require region_stmts() returning one another object
>that will contain the begin/end methods.
>Is it what we want or do I miss s
On 6/12/20 3:02 PM, Richard Biener wrote:
For(gimple. *stmt : bb_vinfo->region_stmts())
Hm, that will require region_stmts() returning one another object
that will contain the begin/end methods.
Is it what we want or do I miss something?
Martin
hanged here.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Martin
Thanks,
Richard
>From 8859cb13a20d91222103577f21af2cd029344a5d Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Thu, 11 Jun 2020 13:25:40 +0200
Subject: [PATCH] vectorizer: add _bb_vec_info::const
On June 12, 2020 2:55:49 PM GMT+02:00, "Martin Liška" wrote:
>On 6/12/20 1:43 PM, Richard Sandiford wrote:
>> Martin Liška writes:
>>> On 6/12/20 12:46 PM, Richard Sandiford wrote:
Martin Liška writes:
> Hello.
>
> I'm working one extension of SLP which will allow to vectorize
>
Martin Liška writes:
> diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-patterns.c
> index 636ad59c001..eac372e6abc 100644
> --- a/gcc/tree-vect-patterns.c
> +++ b/gcc/tree-vect-patterns.c
> @@ -5120,20 +5120,12 @@ vect_determine_precisions (vec_info *vinfo)
>else
> {
>bb_vec
0:00:00 2001
From: Martin Liska
Date: Thu, 11 Jun 2020 13:25:40 +0200
Subject: [PATCH] vectorizer: add _bb_vec_info::const_iterator
gcc/ChangeLog:
* tree-vect-patterns.c (vect_determine_precisions): Use the
iterator.
(vect_pattern_recog): Likewise.
* tree-vect-slp.c (_bb_vec_info::_bb_vec_
Martin Liška writes:
> On 6/12/20 12:46 PM, Richard Sandiford wrote:
>> Martin Liška writes:
>>> Hello.
>>>
>>> I'm working one extension of SLP which will allow to vectorize multiple
>>> BBs. This is a first step where I abstract _bb_vec_info::region_begin and
>>> _bb_vec_info::region end by pro
etc.?
Thanks,
Richard
>From 9e1a01e2e3a2075cf5ac2b2edb3fa969b198d342 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Thu, 11 Jun 2020 13:25:40 +0200
Subject: [PATCH] vectorizer: add _bb_vec_info::const_iterator
gcc/ChangeLog:
* tree-vect-patterns.c (vect_determine_precisions): Use the
iterator.
(vect_pattern_re
Martin Liška writes:
> Hello.
>
> I'm working one extension of SLP which will allow to vectorize multiple
> BBs. This is a first step where I abstract _bb_vec_info::region_begin and
> _bb_vec_info::region end by providing an iterator.
Nice.
> diff --git a/gcc/tree-vectorizer.h b/gcc/tree-vectori
Hello.
I'm working one extension of SLP which will allow to vectorize multiple
BBs. This is a first step where I abstract _bb_vec_info::region_begin and
_bb_vec_info::region end by providing an iterator.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installe
28 matches
Mail list logo
