on 2021/8/25 上午5:56, Segher Boessenkool wrote:
> On Fri, Aug 13, 2021 at 11:18:46AM +0800, Kewen.Lin wrote:
>> on 2021/8/12 下午11:51, Segher Boessenkool wrote:
>>> It is a bad idea to initialise things unnecessary: it hinders many
>>> optimisations, but much more import
on 2021/8/24 下午9:02, Segher Boessenkool wrote:
> Hi Ke Wen,
>
> On Mon, Aug 09, 2021 at 10:53:00AM +0800, Kewen.Lin wrote:
>> on 2021/8/6 下午9:10, Bill Schmidt wrote:
>>> On 8/4/21 9:06 PM, Kewen.Lin wrote:
>>>> The existing vec_unpacku_{hi,lo} supports emulat
Hi Richi,
on 2021/8/23 下午10:33, Richard Biener via Gcc-patches wrote:
> This removes --param vect-inner-loop-cost-factor in favor of looking
> at the estimated number of iterations of the inner loop
> when available and otherwise just assumes a single inner
> iteration which is conservative on
Hi Martin,
on 2021/8/20 上午12:30, Martin Sebor wrote:
> On 8/19/21 9:03 AM, Martin Sebor wrote:
>> On 8/18/21 11:56 PM, Kewen.Lin wrote:
>>> Hi David,
>>>
>>> on 2021/8/19 上午11:26, David Edelsohn via Gcc-patches wrote:
>>>> Hi, Martin
>>&g
Hi David,
on 2021/8/19 上午11:26, David Edelsohn via Gcc-patches wrote:
> Hi, Martin
>
> A few PowerPC-specific testcases started failing yesterday on AIX with
> a strange failure mode: the compiler runs out of memory. As you may
> expect from telling you this in an email reply to your patch, I
Hi Richi,
Thanks for the comments!
on 2021/8/16 下午2:49, Richard Biener wrote:
> On Mon, Aug 16, 2021 at 8:03 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> IIUC, the function vectorizable_bb_reduc_epilogue missed to
>> consider the cost to extract the final value from t
Hi,
IIUC, the function vectorizable_bb_reduc_epilogue missed to
consider the cost to extract the final value from the vector
for reduc operations. This patch is to add one time of
vec_to_scalar cost for extracting.
Bootstrapped & regtested on powerpc64le-linux-gnu P9.
The testing on x86_64 and
on 2021/8/12 下午11:51, Segher Boessenkool wrote:
> On Thu, Aug 12, 2021 at 10:10:10AM +0800, Kewen.Lin wrote:
>>> + enum rs6000_builtins vname = RS6000_BUILTIN_COUNT;
>>>
>>> Using this as a flag value looks unnecessary. Is this just being done to
>>>
Hi Segher,
Thanks for the review!
on 2021/8/12 下午11:10, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Aug 11, 2021 at 02:56:11PM +0800, Kewen.Lin wrote:
>> * config/rs6000/rs6000.c (rs6000_builtin_md_vectorized_function): Add
>> support for some built-in functions
Hi Bill,
on 2021/8/12 上午12:24, Bill Schmidt wrote:
> Hi Kewen,
>
> On 8/11/21 12:44 AM, Kewen.Lin wrote:
>> Hi,
>>
>> This patch is to make prototypes of some Power10 built-in
>> functions consistent with what's in the documentation, as
>> well as
Hi Bill,
Thanks for your prompt review!
on 2021/8/12 上午12:34, Bill Schmidt wrote:
> Hi Kewen,
>
> FWIW, it's easier on reviewers if you include the patch inline instead of as
> an attachment.
>
> On 8/11/21 1:56 AM, Kewen.Lin wrote:
>> Hi,
>>
>> This
Hi,
This patch is to add the support to make vectorizer able to
vectorize scalar version of some built-in functions with its
corresponding vector version with Power10 support.
Bootstrapped & regtested on powerpc64le-linux-gnu {P9,P10}
and powerpc64-linux-gnu P8.
Is it ok for trunk?
BR,
Kewen
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 in
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:
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
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 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 wr
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
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
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
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,
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
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,
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
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
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
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 t
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!=
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,
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,
This v2 has addressed some review comments/suggestions:
- Use "!=" instead of "<" in function operator!= (const Iter )
- 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* accordingly.
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].
>>
>> Bootst
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 v
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 v
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
>>
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 (obvia
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.
>>
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
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
>
>
> BR
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
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
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 下午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,
>>>>
>>
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/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 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 cu
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.
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,
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,
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.
---
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:
*
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
Hi Richard,
on 2021/6/30 下午11:42, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> 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 w
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
on 2021/6/30 下午4:53, Hongtao Liu wrote:
> On Mon, Jun 28, 2021 at 3:27 PM Kewen.Lin wrote:
>>
>> 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 wr
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_INS
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 FM
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")));
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
>>>> discussio
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
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
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
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:
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 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
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,
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
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 s
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 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 "&&" to th
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 Sa
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
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
>>
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
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
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,
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
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
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
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 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
901 - 1000 of 1393 matches
Mail list logo
