Hi,
This patch is to make prototypes of some Power10 built-in
functions consistent with what's in the documentation, as
well as the vector version. Otherwise, useless conversions
can be generated in gimple IR, and the vectorized versions
will have inconsistent types.
Bootstrapped & regtested on
Hi Bill,
Thanks for the comments!
on 2021/8/6 下午9:10, Bill Schmidt wrote:
> Hi Kewen,
>
> On 8/4/21 9:06 PM, Kewen.Lin wrote:
>> Hi,
>>
>> The existing vec_unpacku_{hi,lo} supports emulated unsigned
>> unpacking for short and char but misses the support for int.
>> This patch adds the support fo
on 2021/8/4 下午8:04, Richard Biener wrote:
> On Wed, Aug 4, 2021 at 12:47 PM Kewen.Lin wrote:
>>
>> on 2021/8/4 下午6:01, Richard Biener wrote:
>>> On Wed, Aug 4, 2021 at 4:36 AM Kewen.Lin wrote:
on 2021/8/3 下午8:08, Richard Biener wrote:
> On Fri, Jul 30, 2021 at 7:20 AM Kewen.Lin wro
Hi,
The existing vec_unpacku_{hi,lo} supports emulated unsigned
unpacking for short and char but misses the support for int.
This patch adds the support for vec_unpacku_{hi,lo}_v4si.
Meanwhile, the current implementation uses vector permutation
way, which requires one extra customized constant ve
on 2021/8/4 下午6:01, Richard Biener wrote:
> On Wed, Aug 4, 2021 at 4:36 AM Kewen.Lin wrote:
>>
>> on 2021/8/3 下午8:08, Richard Biener wrote:
>>> On Fri, Jul 30, 2021 at 7:20 AM Kewen.Lin wrote:
on 2021/7/29 下午4:01, Richard Biener wrote:
> On Fri, Jul 23, 2021 at 10:41 AM Kewen.Lin w
on 2021/8/3 下午8:08, Richard Biener wrote:
> On Fri, Jul 30, 2021 at 7:20 AM Kewen.Lin wrote:
>>
>> 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 Kewe
on 2021/8/2 下午5:11, Richard Biener wrote:
> On Mon, 2 Aug 2021, Kewen.Lin wrote:
>
>> on 2021/8/2 下午3:09, Richard Biener wrote:
>>> On Mon, 2 Aug 2021, Kewen.Lin wrote:
>>>
>>>> on 2021/7/30 下午10:04, Kewen.Lin via Gcc-patches wrote:
>>>>>
on 2021/8/2 下午3:09, Richard Biener wrote:
> On Mon, 2 Aug 2021, Kewen.Lin wrote:
>
>> on 2021/7/30 下午10:04, Kewen.Lin via Gcc-patches wrote:
>>> Hi Richi,
>>>
>>> on 2021/7/30 下午7:34, Richard Biener wrote:
>>>> This adds a gather vectorizati
on 2021/7/30 下午10:04, Kewen.Lin via Gcc-patches wrote:
> 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
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,
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 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 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
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,
This v2 has addressed some review comments/suggestions:
- Us
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
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,
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
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 addressed some review comments/suggestions:
- Use "!=" instead of
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 extending the existing CTOR with an optional argum
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!= (const Iter &rhs)
>> - Add new CTOR loops_list (struct loops *loops, un
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/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's suggestion here[1], to support
range-based for loops for traver
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/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].
>>
>> Bootstrapped and regtested on powerpc64le-linux-gnu
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 vec[2].
>>
>> Bootstrapped and regtested on power
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 vec[2].
>>
>> Bootstrapped and regtested on powerp
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/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
having to explicitly release them) and for t
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
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
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
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 下午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
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/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,
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
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
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'
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 (first_commutative_argument): Add info for IFN_MULH.
* internal-fn.def (IFN_MULH)
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.
>> * tree-vect-patterns.c (vect_recog_mulhs_pattern):
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,
Thanks for the comments!
on 2021/7/13 下午5:35, Richard Biener
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 define_insns as standard pattern
>
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:
Hi,
When I added the support for
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 currently vectorizer
>> doesn't try to vectoriz
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,
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 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 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 existing define_insns as standard
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,
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 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,
With Hongtao's help (thanks), we got the SPEC2017 performance
evaluation result on x86_64 (see [1]), this new parameter
ira-consider-dup-in-all-alts has negative effects on i386.
Since we observed it can benefit ports aarch64 and rs6000, the
param is set as 1 by default, this patch is to disab
rote:
>>>>>
>>>>> Hi!
>>>>>
>>>>> on 2021/6/9 下午1:18, Kewen.Lin via Gcc-patches wrote:
>>>>>> Hi,
>>>>>>
>>>>>> PR100328 has some details about this issue, I am trying to
>>>>>>
Hi Vladimir,
on 2021/6/30 下午11:24, Vladimir Makarov wrote:
>
> On 2021-06-28 2:26 a.m., Kewen.Lin wrote:
>> Hi!
>>
>> on 2021/6/9 下午1:18, Kewen.Lin via Gcc-patches wrote:
>>> Hi,
>>>
>>> PR100328 has some details about this issue, I am tr
ote:
>>>>>
>>>>> Hi!
>>>>>
>>>>> on 2021/6/9 下午1:18, Kewen.Lin via Gcc-patches wrote:
>>>>>> Hi,
>>>>>>
>>>>>> PR100328 has some details about this issue, I am trying to
>>>>
on 2021/6/25 上午3:36, Segher Boessenkool wrote:
> On Thu, Jun 24, 2021 at 05:32:20PM +0800, Kewen.Lin wrote:
>> on 2021/6/24 上午12:58, Segher Boessenkool wrote:
>>> On Wed, Jun 23, 2021 at 12:17:07PM +0800, Kewen.Lin wrote:
>> +#ifdef FLOAT128_HW_INSNS_ISA3_1
>> TFtype __floattikf (TItype_pp
on 2021/6/28 下午3:20, Hongtao Liu wrote:
> On Mon, Jun 28, 2021 at 3:12 PM Hongtao Liu wrote:
>>
>> On Mon, Jun 28, 2021 at 2:50 PM Kewen.Lin wrote:
>>>
>>> Hi!
>>>
>>> on 2021/6/9 下午1:18, Kewen.Lin via Gcc-patches wrote:
>>>> Hi,
&g
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571258.html
BR,
Kewen
on 2021/6/9 上午10:26, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> Gentle ping this:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571258.html
>
> BR,
> Kewen
&
Hi!
I'd like to 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/10 上午4:17, Segher Boessenkool wrote:
>> Hi!
>
Hi!
on 2021/6/9 下午1:18, Kewen.Lin via Gcc-patches wrote:
> 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
on 2021/6/24 上午12:58, Segher Boessenkool wrote:
> On Wed, Jun 23, 2021 at 12:17:07PM +0800, Kewen.Lin wrote:
+#ifdef FLOAT128_HW_INSNS_ISA3_1
TFtype __floattikf (TItype_ppc)
__attribute__ ((__ifunc__ ("__floattikf_resolve")));
>>>
>>> I wonder if we now need TItype_ppc at all any
on 2021/6/23 下午3:22, Richard Biener wrote:
> On Tue, Jun 22, 2021 at 4:35 AM Kewen.Lin wrote:
>>
>> Hi Richi and Martin,
>>
Thanks Richi! One draft (not ready for review) is attached for the further
discussion. It follows the idea of RAII-style cleanup. I noticed that
Martin
Hi Martin,
on 2021/6/23 上午12:14, Martin Sebor wrote:
> On 6/21/21 8:35 PM, Kewen.Lin wrote:
>> Hi Richi and Martin,
>>
Thanks Richi! One draft (not ready for review) is attached for the further
discussion. It follows the idea of RAII-style cleanup. I noticed that
Martin sugg
Hi Segher,
Thanks for the prompt review!
on 2021/6/23 上午2:56, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jun 21, 2021 at 05:27:06PM +0800, Kewen.Lin wrote:
>> Recently if we build gcc on Power with the assembler which doesn't
>> have Power10 support, the build will fail when building libgcc wit
Hi Richi and Martin,
>>
>> Thanks Richi! One draft (not ready for review) is attached for the further
>> discussion. It follows the idea of RAII-style cleanup. I noticed that
>> Martin suggested stepping forward to make tree_predictive_commoning_loop
>> and its callees into one class (Thanks Ma
Hi,
Recently if we build gcc on Power with the assembler which doesn't
have Power10 support, the build will fail when building libgcc with
one error message like:
Error: invalid switch -mpower10
Error: unrecognized option -mpower10
make[2]: *** [...gcc/gcc-base/libgcc/shared-object.mk:14: float12
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_table_tick >= label_tick_ebb_start))
>> rsp->last_
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 required for lxsi[bh]zx and mvex
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 convert them to
>> double/
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,
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,
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/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
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 do some refactoring.
>>
>> Bootstrapped/regtes
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 下午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
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 Sandiford wrote:
Richard Biener writes:
> So wh
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/ChangeLog:
* config/cris/cris.md (*addi_reload): Fix empty
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
>> it will become harder to mess t
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 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 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
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 use empty split condition
if the condition for define_insn isn't empty,
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
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 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
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 suggested, this patch is to emit the error message
if the split
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
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 下午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
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/gcc/vec-perm-indices.c
>> @@ -101,6 +101,70 @@ vec_
>> 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 =
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
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569792.html
BR,
Kewen
on 2021/5/7 上午10:30, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> For some cases that when we load unsigned char/short values from
> the appropriate unsigned char/short memories and con
Hi,
This is the updated version of patch to deal with the bwaves_r
degradation due to vector construction fed by strided loads.
As Richi's comments [1], this follows the similar idea to over
price the vector construction fed by VMAT_ELEMENTWISE or
VMAT_STRIDED_SLP. Instead of adding the extra co
on 2021/5/24 下午3:21, Kewen.Lin via Gcc-patches wrote:
> Hi Andre,
>
> on 2021/5/24 下午2:17, Andre Vieira (lists) via Gcc-patches wrote:
>> Hi,
>>
>> When vectorizing with --param vect-partial-vector-usage=1 the vectorizer
>> uses an unpredicated (all-true p
Hi Andre,
on 2021/5/24 下午2:17, Andre Vieira (lists) via Gcc-patches wrote:
> Hi,
>
> When vectorizing with --param vect-partial-vector-usage=1 the vectorizer uses
> an unpredicated (all-true predicate for SVE) main loop and a predicated tail
> loop. The way this was implemented seems to mean it
on 2021/5/20 下午6:25, Richard Biener wrote:
> On Thu, May 20, 2021 at 12:09 PM Kewen.Lin wrote:
>>
>> on 2021/5/20 下午5:30, Christophe Lyon wrote:
>>> On Thu, 20 May 2021 at 10:52, Kewen.Lin via Gcc-patches
>>> wrote:
>>>>
>>>> on 2021/5/19
on 2021/5/20 下午5:30, Christophe Lyon wrote:
> On Thu, 20 May 2021 at 10:52, Kewen.Lin via Gcc-patches
> wrote:
>>
>> on 2021/5/19 下午6:01, Richard Biener wrote:
>>> On Wed, May 19, 2021 at 11:47 AM Kewen.Lin wrote:
>>>>
>>>> Hi Richi,
>>&g
on 2021/5/19 下午6:01, Richard Biener wrote:
> On Wed, May 19, 2021 at 11:47 AM Kewen.Lin wrote:
>>
>> Hi Richi,
>>
>> on 2021/5/19 下午4:15, Richard Biener wrote:
>>> On Wed, May 19, 2021 at 8:20 AM Kewen.Lin wrote:
Hi,
This patch is to replace the current hardcoded weight factor
701 - 800 of 1024 matches
Mail list logo