Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562015.html
BR,
Kewen
on 2021/5/7 上午10:45, Kewen.Lin via Gcc-patches wrote:
> Hi Segher,
>
>>>
>>> I think this should be postponed to stage 1 though? Or is there
>>> anything ver
>> The attached patch v2 use the structure by considering the above
>> advice and the (code == CONSTRUCTOR || code == VECTOR_CST) part
>> can be shared with VIEW_CONVERT_EXPR handlings as below:
>>
>> op0 gathering (leave V_C_E in code if it's met)
>>
>> else if (code == CONSTRUCTOR || code =
on 2021/5/27 下午8:55, Richard Sandiford wrote:
> Sorry for the slow reponse.
>
> "Kewen.Lin" writes:
>> diff --git a/gcc/vec-perm-indices.c b/gcc/vec-perm-indices.c
>> index ede590dc5c9..57dd11d723c 100644
>> --- a/gcc/vec-perm-indices.c
>> +++ b/
Hi Claudiu,
on 2021/6/2 下午2:52, Claudiu Zissulescu wrote:
> Hi,
>
> Indeed, the split condition needs to be populated. However, I doubt that the
> pattern in question is used by the compiler. Do you have an example where it
> is exercised?
>
Thanks for the reply! Sorry that I don't have an e
Hi Richi,
on 2021/6/2 下午3:04, Richard Biener wrote:
> On Wed, Jun 2, 2021 at 7:05 AM Kewen Lin wrote:
>>
>> As Segher suggested, this patch is to emit the error message
>> if the split condition of define_insn_and_split is empty while
>> the insn condition isn't.
>
> I wonder whether it would be
Hi Claudiu,
on 2021/6/2 下午3:12, Claudiu Zissulescu wrote:
> Hi Kewen,
>
> Maybe it is best just to remove the pattern entirely, I couldn't exercise it
> myself. I was secretly hopping someone could do it.
> Please can you submit a patch which removes it if it is not too much trouble?
>
The pat
on 2021/6/2 下午3:43, Richard Biener wrote:
> On Wed, Jun 2, 2021 at 9:28 AM Kewen.Lin wrote:
>>
>> Hi Richi,
>>
>> on 2021/6/2 下午3:04, Richard Biener wrote:
>>> On Wed, Jun 2, 2021 at 7:05 AM Kewen Lin wrote:
>>>>
>>>> As Segher suggeste
Hi Richard,
on 2021/6/2 下午4:11, Richard Sandiford wrote:
> Kewen Lin writes:
>> Hi all,
>>
>> define_insn_and_split should avoid to use empty split condition
>> if the condition for define_insn isn't empty, otherwise it can
>> sometimes result in unexpected consequence, since the split
>> will al
Hi,
As Richi suggested in PR100794, this patch is to remove
some unnecessary update_ssa calls with flag
TODO_update_ssa_only_virtuals, also do some refactoring.
Bootstrapped/regtested on powerpc64le-linux-gnu P9,
x86_64-redhat-linux and aarch64-linux-gnu, built well
on Power9 ppc64le with --with-
Hi,
As PR100794 shows, in the current implementation PRE bypasses
some optimization to avoid introducing loop carried dependence
which stops loop vectorizer to vectorize the loop. At -O2,
there is no downstream pass to re-catch this kind of opportunity
if loop vectorizer fails to vectorize that l
on 2021/6/2 下午5:13, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>
>> on 2021/6/2 锟斤拷锟斤拷4:11, Richard Sandiford wrote:
>>> Kewen Lin writes:
>>>> Hi all,
>>>>
>>>> define_insn_and_split should avoid to
Hi Richard,
on 2021/6/3 上午1:19, Richard Sandiford wrote:
> "Kewen.Lin via Gcc-patches" writes:
>> Hi,
>>
>> As PR100794 shows, in the current implementation PRE bypasses
>> some optimization to avoid introducing loop carried dependence
>> which stops
Hi Richi/Richard/Jeff/Segher,
Thanks for the comments!
on 2021/6/3 上午7:52, Segher Boessenkool wrote:
> On Wed, Jun 02, 2021 at 06:32:13PM +0100, Richard Sandiford wrote:
>> Richard Biener writes:
>>> So what Richard suggests would be to disallow split conditions
>>> that do not start with "&& ",
Hi Nilsson,
on 2021/6/2 下午8:45, Hans-Peter Nilsson wrote:
>> From: Kewen Lin
>> Date: Wed, 2 Jun 2021 07:04:54 +0200
>
>> gcc/ChangeLog:
>>
>> * config/cris/cris.md (*addi_reload): Fix empty split condition.
>> ---
>> gcc/config/cris/cris.md | 2 +-
>> 1 file changed, 1 insertion(+), 1 del
Hi Segher,
on 2021/6/3 下午5:18, Segher Boessenkool wrote:
> On Thu, Jun 03, 2021 at 03:00:44AM -0500, Segher Boessenkool wrote:
>> On Thu, Jun 03, 2021 at 01:22:38PM +0800, Kewen.Lin wrote:
>> The whole point of requiring the split condition to start with && is so
>>
on 2021/6/4 上午12:12, Hans-Peter Nilsson wrote:
>> From: Kewen.Lin
>> Date: Thu, 3 Jun 2021 07:45:57 +0200
>
>> on 2021/6/2 Hans-Peter Nilsson wrote:
>>>> From: Kewen Lin
>>>> Date: Wed, 2 Jun 2021 07:04:54 +0200
>>>
>>>> gcc
on 2021/6/3 下午4:05, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richi/Richard/Jeff/Segher,
>>
>> Thanks for the comments!
>>
>> on 2021/6/3 锟斤拷锟斤拷7:52, Segher Boessenkool wrote:
>>> On Wed, Jun 02, 2021 at 06:32:13PM +0100, Richard Sa
on 2021/6/7 下午3:12, Richard Biener wrote:
> On Fri, Jun 4, 2021 at 4:58 AM Kewen.Lin via Gcc-patches
> wrote:
>>
>> Hi Segher,
>>
>> on 2021/6/3 下午5:18, Segher Boessenkool wrote:
>>> On Thu, Jun 03, 2021 at 03:00:44AM -0500, Segher Boessenkool wrote:
>&g
Hi Segher,
on 2021/6/8 上午7:50, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Jun 04, 2021 at 10:57:51AM +0800, Kewen.Lin via Gcc-patches wrote:
>> To find out those need fixing seems to be the critical part. It's
>> not hard to add one explicit "&&"
on 2021/6/7 下午10:46, Richard Biener wrote:
> On Wed, Jun 2, 2021 at 11:29 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> As Richi suggested in PR100794, this patch is to remove
>> some unnecessary update_ssa calls with flag
>> TODO_update_ssa_only_virtuals, also
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571258.html
BR,
Kewen
on 2021/5/26 上午10:59, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> This is the updated version of patch to deal with the bwaves_r
> degradation due to vector construction fed by strided lo
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569792.html
BR,
Kewen
on 2021/5/26 上午11:02, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> Gentle ping this:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569792.html
>
>
> BR,
>
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562015.html
BR,
Kewen
on 2021/5/26 上午11:04, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> Gentle ping this:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562015.html
>
> BR,
> K
Hi,
PR100328 has some details about this issue, I am trying to
brief it here. In the hottest function LBM_performStreamCollideTRT
of SPEC2017 bmk 519.lbm_r, there are many FMA style expressions
(27 FMA, 19 FMS, 11 FNMA). On rs6000, this kind of FMA style
insn has two flavors: FLOAT_REG and VSX_R
Hi Segher,
Thanks for the review!
on 2021/6/10 上午7:23, Segher Boessenkool wrote:
> Hi!
>
> On Fri, May 07, 2021 at 10:30:38AM +0800, Kewen.Lin wrote:
>> For some cases that when we load unsigned char/short values from
>> the appropriate unsigned char/short memories and conv
Hi Segher,
on 2021/6/10 下午6:58, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Jun 10, 2021 at 05:32:23PM +0800, Kewen.Lin wrote:
>> +/* { dg-do compile { target lp64 } } */
>
> One final thing: what requires lp64 here? Could you try without please?
>
The lp64 is req
Hi Segher,
Thanks for the review!
on 2021/6/10 上午4:17, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Dec 16, 2020 at 04:49:49PM +0800, Kewen.Lin wrote:
>> Currently we have the check:
>>
>> if (!insn
>>|| (value && rsp->last_set_tabl
Hi,
This patch fixes the typos introduced by commit r12-4240.
The dg-warning format looks like:
{ dg-warning regexp [comment [{ target/xfail selector } [line] ]] }
Some dg-warnings such as:
{ dg-warning "\\\[-Wstringop-overflow" { target { i?86-*-* x86_64-*-* } } }
miss the comment field, it
Hi Hongtao,
on 2021/10/11 上午10:10, liuhongt via Gcc-patches wrote:
> libgomp/ChangeLog:
>
> * testsuite/libgomp.graphite/force-parallel-8.c: Add
> -fno-tree-vectorize.
> ---
> libgomp/testsuite/libgomp.graphite/force-parallel-8.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Hi,
As PR102658 shows, commit r12-4240 enables vectorization at O2,
some cases need to be adjusted accordingly for rs6000 port.
- For target specific test cases, this adds -fno-tree-vectorize
to retain original test points, otherwise vectorization can
make some expected scalar instructions gone o
Hi Segher,
Thanks for the comments.
on 2021/10/1 上午6:13, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Sep 30, 2021 at 11:06:50AM +0800, Kewen.Lin wrote:
>
> [ huge snip ]
>
>> Based on the understanding and testing, I think it's safe to adopt this
>> patch.
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572555.html
BR,
Kewen
>>> on 2021/6/11 下午9:16, Kewen.Lin via Gcc-patches wrote:
>>>> Hi Segher,
>>>>
>>>> Thanks for the review!
>>>>
>>>> on 2021/6/1
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580358.html
BR,
Kewen
on 2021/9/28 下午4:16, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> This patch follows the discussions here[1][2], where Segher
> pointed out the existing way to guard the extra pena
>> on 2021/9/1 下午2:55, Kewen.Lin via Gcc-patches wrote:
>>> Hi!
>>>
>>> This patch is to fix the inconsistent behaviors for non-LTO mode
>>> and LTO mode. As Martin pointed out, currently the function
>>> rs6000_can_inline_p simply makes it inlin
Hi Bill!
on 2021/10/13 上午12:36, Bill Schmidt wrote:
> Hi Kewen,
>
> On 10/11/21 1:30 AM, Kewen.Lin wrote:
>> Hi Segher,
>>
>> Thanks for the comments.
>>
>> on 2021/10/1 上午6:13, Segher Boessenkool wrote:
>>> Hi!
>>>
>>> On Thu,
8 AM Martin Sebor via Gcc-patches
>>>> wrote:
>>>>>
>>>>> On 10/11/21 11:43 AM, Segher Boessenkool wrote:
>>>>>> On Mon, Oct 11, 2021 at 10:23:03AM -0600, Martin Sebor wrote:
>>>>>>> On 10/11/21 9:30 AM, Segher Boessen
Hi Hongtao,
on 2021/10/14 下午3:11, liuhongt wrote:
> Hi Kewen:
> Cound you help to verify if this patch fix those regressions
> for rs6000 port.
>
The ppc64le run just finished, there are still some regresssions:
NA->XPASS: c-c++-common/Wstringop-overflow-2.c -Wc++-compat (test for
warning
on 2021/10/14 下午6:56, Kewen.Lin via Gcc-patches wrote:
> Hi Hongtao,
>
> on 2021/10/14 下午3:11, liuhongt wrote:
>> Hi Kewen:
>> Cound you help to verify if this patch fix those regressions
>> for rs6000 port.
>>
>
> The ppc64le run just finished, the
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572555.html
BR,
Kewen
>
>>>> on 2021/6/11 下午9:16, Kewen.Lin via Gcc-patches wrote:
>>>>> Hi Segher,
>>>>>
>>>>> Thanks for the review!
>>
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580358.html
BR,
Kewen
> on 2021/9/28 下午4:16, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> This patch follows the discussions here[1][2], where Segher
>> pointed out the existing way t
>>> on 2021/9/1 下午2:55, Kewen.Lin via Gcc-patches wrote:
>>>> Hi!
>>>>
>>>> This patch is to fix the inconsistent behaviors for non-LTO mode
>>>> and LTO mode. As Martin pointed out, currently the function
>>>> rs6000_can_inl
Hi,
As the discussions and the testing result under the main thread, this
patch would be safe.
Ping for this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580357.html
BR,
Kewen
on 2021/9/28 下午4:13, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As the discussion in
Hi,
As PR102789 shows, when vectorizer does some peelings for alignment
in prologue, function vect_update_inits_of_drs would update the
inits of some drs. But as the failed case, we shouldn't update the
dr for simd_lane_access, it has the fixed-length storage mainly for
the main loop, the update
Hi,
As PR102767 shows, the commit r12-3482 exposed one ICE in function
rs6000_builtin_vectorization_cost. We claims V1TI supports movmisalign
on rs6000 (See define_expand "movmisalign"), so it return true in
rs6000_builtin_support_vector_misalignment for misalign 8. Later in
the cost querying rs
Hi,
As PR102897 shows, there is one incorrect assertion in function
simplify_permutation, which is based on the wrong assumption that
all cases with op2_type == tgt_type are handled previously, the
proposed fix is to remove this wrong assertion.
Bootstrapped and regtested on x86_64-redhat-linux,
Hi Richi,
on 2021/10/26 下午3:50, Richard Biener wrote:
> On Tue, Oct 26, 2021 at 5:40 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> As PR102897 shows, there is one incorrect assertion in function
>> simplify_permutation, which is based on the wrong assumption that
>>
Hi Jakub,
on 2021/10/27 下午3:51, Jakub Jelinek wrote:
> On Tue, Oct 26, 2021 at 11:40:01AM +0800, Kewen.Lin via Gcc-patches wrote:
>> gcc/testsuite/ChangeLog:
>>
>> * gcc.dg/pr102897.c: New test.
>
> The testcase FAILs on i686-linux due to:
> FAIL: gcc.dg/pr10
Hi David,
Thanks for the review!
on 2021/10/27 下午9:12, David Edelsohn wrote:
> On Sun, Oct 24, 2021 at 11:04 PM Kewen.Lin wrote:
>>
>> Hi,
>>
>> As PR102767 shows, the commit r12-3482 exposed one ICE in function
>> rs6000_builtin_vectorization_cost. We claim
on 2021/10/28 上午9:43, David Edelsohn wrote:
> On Wed, Oct 27, 2021 at 9:30 PM Kewen.Lin wrote:
>>
>> Hi David,
>>
>> Thanks for the review!
>>
>> on 2021/10/27 下午9:12, David Edelsohn wrote:
>>> On Sun, Oct 24, 2021 at 11:04 PM Kewen.Lin wrote
Hi,
This patch is to add test cases to check if vectorizer
can exploit vector multiply instrutions on Power, some
of them are supported since Power8, the other are newly
introduced by Power10.
Is it ok for trunk?
BR,
Kewen
-
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/mul-vectoriz
Hi,
This patch is to add one test case to check if vectorizer
can exploit vector division instrutions newly introduced
by Power10.
Is it ok for trunk?
BR,
Kewen
-
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/div-vectorize-1.c: New test.
---
.../gcc.target/powerpc/div-vectorize-1.c
Hi,
This patch is to make Power10 newly introduced vector
modulo instructions exploited in vectorized loops, it
just simply renames existing define_insns as standard
pattern names.
Is it ok for trunk?
BR,
Kewen
-
gcc/ChangeLog:
* config/rs6000/rs6000-builtin.def (MODS_V2DI, MODS_V4S
Hi Segher,
on 2021/7/8 上午1:10, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Jul 07, 2021 at 05:03:23PM +0800, Kewen.Lin wrote:
>> This patch is to make Power10 newly introduced vector
>> modulo instructions exploited in vectorized loops, it
>> just simply renames existi
Hi Richard,
on 2021/7/8 下午8:38, Richard Sandiford via Gcc-patches wrote:
> Quoting from the final patch in the series:
>
>
> This patch adds support for reusing a main loop's reduction accumulator
> in an epilogue loop. Thi
Hi,
When I added the support for Power10 newly introduced multiply
highpart instrutions, I noticed that currently vectorizer
doesn't try to vectorize multiply highpart pattern, I hope
this isn't intentional?
This patch is to extend the existing pattern mulhs handlings
to cover multiply highpart.
Hi,
This patch is to make Power10 newly introduced vector
multiply high (part) instructions exploited in vectorized
loops, it renames existing define_insns as standard pattern
names. It depends on that patch which enables vectorizer
to recog mul_highpart.
Tested on powerpc64le-linux-gnu P9 with
Hi Richi,
Thanks for the comments!
on 2021/7/13 下午5:35, Richard Biener wrote:
> On Tue, Jul 13, 2021 at 10:53 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> When I added the support for Power10 newly introduced multiply
>> highpart instrutions, I noticed that curre
on 2021/7/13 下午8:42, Richard Biener wrote:
> On Tue, Jul 13, 2021 at 12:25 PM Kewen.Lin wrote:
>>
>> Hi Richi,
>>
>> Thanks for the comments!
>>
>> on 2021/7/13 下午5:35, Richard Biener wrote:
>>> On Tue, Jul 13, 2021 at 10:53 AM Kewen.Lin wrote:
on 2021/7/14 上午6:07, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Jul 13, 2021 at 04:58:42PM +0800, Kewen.Lin wrote:
>> This patch is to make Power10 newly introduced vector
>> multiply high (part) instructions exploited in vectorized
>> loops, it renames existing defin
on 2021/7/14 下午2:38, Richard Biener wrote:
> On Tue, Jul 13, 2021 at 4:59 PM Kewen.Lin wrote:
>>
>> on 2021/7/13 下午8:42, Richard Biener wrote:
>>> On Tue, Jul 13, 2021 at 12:25 PM Kewen.Lin wrote:
>>>>
>>>> Hi Richi,
>>>>
>>
Hi Richard,
on 2021/7/14 下午4:38, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> gcc/ChangeLog:
>>
>> * internal-fn.c (first_commutative_argument): Add info for IFN_MULH.
>> * internal-fn.def (IFN_MULH): New internal function.
>> * tre
on 2021/7/14 下午7:32, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>
>> on 2021/7/14 下午4:38, Richard Sandiford wrote:
>>> "Kewen.Lin" writes:
>>>> gcc/ChangeLog:
>>>>
>>>>* internal-fn.c (f
on 2021/7/15 上午3:32, Segher Boessenkool wrote:
> On Wed, Jul 14, 2021 at 12:32:24PM +0100, Richard Sandiford wrote:
>> TBH, 79 vs. 80 isn't normally something I'd worry about when reviewing
>> new code. But I know in the past people have asked for 79 to be used
>> for the “end+1” reason, so I don'
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571258.html
BR,
Kewen
on 2021/6/28 下午3:01, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> Gentle ping this:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571258.html
>
> BR,
> Kewen
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572555.html
BR,
Kewen
on 2021/6/28 下午3:00, Kewen.Lin via Gcc-patches wrote:
> Hi!
>
> I'd like to gentle ping this:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572555.html
>
>
&g
on 2021/7/14 下午3:45, Kewen.Lin via Gcc-patches wrote:
> on 2021/7/14 下午2:38, Richard Biener wrote:
>> On Tue, Jul 13, 2021 at 4:59 PM Kewen.Lin wrote:
>>>
>>> on 2021/7/13 下午8:42, Richard Biener wrote:
>>>> On Tue, Jul 13, 2021 at 12:25 PM Kewen.Lin wrote
Hi Uros,
on 2021/7/15 下午3:17, Uros Bizjak wrote:
> On Thu, Jul 15, 2021 at 9:07 AM Kewen.Lin wrote:
>>
>> on 2021/7/14 下午3:45, Kewen.Lin via Gcc-patches wrote:
>>> on 2021/7/14 下午2:38, Richard Biener wrote:
>>>> On Tue, Jul 13, 2021 at 4:59 PM Kewen.Lin wr
on 2021/7/15 下午4:04, Kewen.Lin via Gcc-patches wrote:
> Hi Uros,
>
> on 2021/7/15 下午3:17, Uros Bizjak wrote:
>> On Thu, Jul 15, 2021 at 9:07 AM Kewen.Lin wrote:
>>>
>>> on 2021/7/14 下午3:45, Kewen.Lin via Gcc-patches wrote:
>>>> on 2021/7/14 下午2:3
on 2021/7/15 下午4:23, Uros Bizjak wrote:
> On Thu, Jul 15, 2021 at 10:04 AM Kewen.Lin wrote:
>>
>> Hi Uros,
>>
>> on 2021/7/15 下午3:17, Uros Bizjak wrote:
>>> On Thu, Jul 15, 2021 at 9:07 AM Kewen.Lin wrote:
>>>>
>>>> on 2021/7/14 下午3:45
on 2021/7/15 下午7:58, Richard Biener wrote:
> On Thu, Jul 15, 2021 at 10:41 AM Kewen.Lin wrote:
>>
>> on 2021/7/15 下午4:04, Kewen.Lin via Gcc-patches wrote:
>>> Hi Uros,
>>>
>>> on 2021/7/15 下午3:17, Uros Bizjak wrote:
>>>> On Thu, Jul 15, 2021 a
Hi,
This patch follows Martin's suggestion here[1], to support
range-based for loops for traversing loops, analogously to
the patch for vec[2].
Bootstrapped and regtested on powerpc64le-linux-gnu P9,
x86_64-redhat-linux and aarch64-linux-gnu, also
bootstrapped on ppc64le P9 with bootstrap-O3 conf
Hi Martin & Richard,
>> A further improvement worth considering (if you're so inclined :)
>> is replacing the pcom_worker vec members with auto_vec (obviating
>> having to explicitly release them) and for the same reason also
>> replacing the comp_ptrs bare pointer members with auto_vecs.
>> There
on 2021/7/20 上午4:45, Martin Sebor wrote:
> On 7/19/21 12:28 AM, Kewen.Lin wrote:
>> Hi Martin & Richard,
>>
>>>> A further improvement worth considering (if you're so inclined :)
>>>> is replacing the pcom_worker vec members with auto_vec (obviating
on 2021/7/19 下午2:26, Andrew Pinski wrote:
> On Sun, Jul 18, 2021 at 11:21 PM Kewen.Lin via Gcc-patches
> wrote:
>>
>> Hi,
>>
>> This patch follows Martin's suggestion here[1], to support
>> range-based for loops for traversing loops, analogously to
>&g
on 2021/7/19 下午10:08, Jonathan Wakely wrote:
> On Mon, 19 Jul 2021 at 07:20, Kewen.Lin wrote:
>>
>> Hi,
>>
>> This patch follows Martin's suggestion here[1], to support
>> range-based for loops for traversing loops, analogously to
>> the patch for
on 2021/7/19 下午10:34, Richard Biener wrote:
> On Mon, Jul 19, 2021 at 8:20 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> This patch follows Martin's suggestion here[1], to support
>> range-based for loops for traversing loops, analogously to
>> the patch for
on 2021/7/19 下午11:59, Martin Sebor wrote:
> On 7/19/21 12:20 AM, Kewen.Lin wrote:
>> Hi,
>>
>> This patch follows Martin's suggestion here[1], to support
>> range-based for loops for traversing loops, analogously to
>> the patch for vec[2].
>>
>> B
Hi,
This v2 has addressed some review comments/suggestions:
- Use "!=" instead of "<" in function operator!= (const Iter &rhs)
- Add new CTOR loops_list (struct loops *loops, unsigned flags)
to support loop hierarchy tree rather than just a function,
and adjust to use loops* according
on 2021/7/20 下午5:49, Jonathan Wakely wrote:
> On Tue, 20 Jul 2021 at 09:58, Kewen.Lin wrote:
>>
>> on 2021/7/19 下午11:59, Martin Sebor wrote:
>>> On 7/19/21 12:20 AM, Kewen.Lin wrote:
>>>> Hi,
>>>>
>>>> This patch follows Martin
Hi,
Comparing to v2, this v3 removed the new CTOR with struct loops *loops
as Richi clarified. I'd like to support it in a separated follow up
patch by extending the existing CTOR with an optional argument loop_p
root.
Bootstrapped and regtested again on powerpc64le-linux-gnu P9,
x86_64-redhat-l
on 2021/7/22 下午8:56, Richard Biener wrote:
> On Tue, Jul 20, 2021 at 4:37
> PM Kewen.Lin wrote:
>>
>> Hi,
>>
>> This v2 has addressed some review comments/suggestions:
>>
>> - Use "!=" instead of "<" in function operator!= (con
on 2021/7/24 上午12:10, Martin Sebor wrote:
> On 7/23/21 2:35 AM, Kewen.Lin wrote:
>> Hi,
>>
>> Comparing to v2, this v3 removed the new CTOR with struct loops *loops
>> as Richi clarified. I'd like to support it in a separated follow up
>> patch by extend
on 2021/7/24 上午12:26, Martin Sebor wrote:
> On 7/23/21 2:41 AM, Kewen.Lin wrote:
>> on 2021/7/22 下午8:56, Richard Biener wrote:
>>> On Tue, Jul 20, 2021 at 4:37
>>> PM Kewen.Lin wrote:
>>>>
>>>> Hi,
>>>>
>>>> This v2 has
Hi,
As PR101596 showed, vect_recog_mulhs_pattern uses target_precision to
check the scale_term is expected or not, it could be wrong when the
precision of the actual used new_type larger than target_precision as
shown by the example.
This patch is to use precision of new_type instead of target_pr
Hi William,
Thanks for the review comments!
on 2021/7/28 上午6:25, will schmidt wrote:
> On Wed, 2021-05-26 at 10:59 +0800, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>
>
> Hi,
>
>
>> This is the updated version of patch to deal with the bwaves_r
>>
Hi,
v2: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571258.html
This v3 addressed William's review comments in
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576154.html
It's mainly to deal with the bwaves_r degradation due to vector
construction fed by strided loads.
As Richi's com
on 2021/7/29 下午4:01, Richard Biener wrote:
> On Fri, Jul 23, 2021 at 10:41 AM Kewen.Lin wrote:
>>
>> on 2021/7/22 下午8:56, Richard Biener wrote:
>>> On Tue, Jul 20, 2021 at 4:37
>>> PM Kewen.Lin wrote:
>>>>
>>>> Hi,
>>
Hi Ruoyao,
on 2021/7/30 下午12:57, Xi Ruoyao via Gcc-patches wrote:
> Ping again.
>
This ping-ed patch has been approved by Richard at
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576001.html
Just chime in as I guess you didn't receive his mail somehow.
BR,
Kewen
> On Sun, 2021-07-11 at
Hi Thomas,
on 2021/7/30 下午3:18, Thomas Schwinge wrote:
> Hi!
>
> Thanks for this nice clean-up.
>
> Curious why in some instances we're not removing the 'class loop *loop'
> declaration, I had a look, and this may suggest some further clean-up?
> (See below; so far, all untested!)
>
>
Yeah, s
Hi,
This patch is to fix the typos in the move_sese_region_to_fn.
As mentioned here [1], I tried to debug the test case
gcc.dg/graphite/pr83359.c with trunk, but I found it didn't
go into the hunk guard with "if (moved_orig_loop_num)". So
I switched to commit 555758de90074 (also reproduced the IC
Hi Richi,
on 2021/7/30 下午7:34, Richard Biener wrote:
> This adds a gather vectorization capability to the vectorizer
> without target support by decomposing the offset vector, doing
> sclar loads and then building a vector from the result. This
> is aimed mainly at cases where vectorizing the res
Hi,
When I was investigating density_test heuristics, I noticed that
the current rs6000_density_test could be used for single scalar
iteration cost calculation, through the call trace:
vect_compute_single_scalar_iteration_cost
-> rs6000_finish_cost
-> rs6000_density_test
It looks u
Hi,
We noticed that SPEC2017 503.bwaves_r run time degrades by about 8%
on P8 and P9 if we enabled vectorization at O2 fast-math.
Comparing to Ofast, compiler doesn't do the loop interchange on the
innermost loop, it's not profitable to vectorize it then. Since
with loop vectorization, the loop
Hi,
For some cases that when we load unsigned char/short values from
the appropriate unsigned char/short memories and convert them to
double/single precision floating point value, there would be
implicit conversions to int first. It makes GCC not leverage the
P9 instructions lxsibzx/lxsihzx. Thi
Hi,
This patch is to teach forwprop to optimize some cases where the
permutated operands of vector permutation are from two same type
CTOR and CTOR or one CTOR and one VECTOR CST. It aggressively
takes VIEW_CONVERT_EXPR as trivial copies and transform the vector
permutation into vector CTOR.
Bo
Hi Segher,
>>
>> I think this should be postponed to stage 1 though? Or is there
>> anything very urgent in it?
>>
>
> Yeah, I agree that this belongs to stage1, and there isn't anything
> urgent about it. Thanks for all further comments above!
>
Gentle ping this:
https://gcc.gnu.org/piperma
Hi Richi,
Thanks for the comments!
on 2021/5/7 下午5:43, Richard Biener wrote:
> On Fri, May 7, 2021 at 5:30 AM Kewen.Lin via Gcc-patches
> wrote:
>>
>> Hi,
>>
>> When I was investigating density_test heuristics, I noticed that
>> the current rs6000_density_
Hi,
v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569790.html
This is the updated version with one new parameter costing_for_scalar
passed by init_cost hook, instead of checking the passed data point
identity.
Bootstrapped/regtested on powerpc64le-linux-gnu P9.
Is it ok for trunk?
BR,
Hi,
This patch is to move rs6000_vect_nonmem (target cost_data
related information) into target cost_data struct.
Following Richi's comments in the thread[1], we can gather
data from add_stmt_cost invocations. This is one pre-step
to centralize target cost_data related stuffs.
Is it ok for trun
Hi Will,
Thanks for the comments!
on 2021/5/7 下午7:43, will schmidt wrote:
> On Fri, 2021-05-07 at 10:28 +0800, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> When I was investigating density_test heuristics, I noticed that
>> the current rs6000_density_test coul
1101 - 1200 of 1615 matches
Mail list logo
