Hi Segher,
on 2022/9/1 23:04, Segher Boessenkool wrote:
> On Thu, Sep 01, 2022 at 05:05:44PM +0800, Kewen.Lin wrote:
>>> On Wed, Aug 31, 2022 at 05:33:28PM +0800, Kewen.Lin wrote:
>>> *Should* -mpowerpc64 be disabled by -m32?
>>
>> I think the reason to disab
Hi Jeff,
Thanks for the patch, some comments on nits are inline.
on 2022/9/1 11:24, Jiufu Guo wrote:
> Hi,
>
> As mentioned in PR106550, since pli could support 34bits immediate, we could
> use less instructions(3insn would be ok) to build 64bits constant with pli.
>
> For example, for constant
on 2022/9/2 11:23, HAO CHEN GUI wrote:
> Hi Kewen,
>
> On 1/9/2022 下午 5:34, Kewen.Lin wrote:
>> Thanks for the updated patch!
>>
>> I just found that it seems all the three test cases suffer the empty
>> TU error issue from those has_arch* effective target checks
on 2022/9/3 01:36, Segher Boessenkool wrote:
> On Fri, Sep 02, 2022 at 08:50:52AM +0800, Kewen.Lin wrote:
>> on 2022/9/1 22:57, Segher Boessenkool wrote:
>>> These two are independent, but apparently we have a bug here, which will
>>> make what you did malfunction in
on 2022/9/3 01:44, Segher Boessenkool wrote:
> On Fri, Sep 02, 2022 at 08:51:01AM +0800, Kewen.Lin wrote:
>> on 2022/9/1 23:04, Segher Boessenkool wrote:
>>> On Thu, Sep 01, 2022 at 05:05:44PM +0800, Kewen.Lin wrote:
>>>> Without any explicit -mpowerpc64 (and -mno-),
on 2022/9/1 22:17, Peter Bergner wrote:
> On 9/1/22 3:29 AM, Kewen.Lin wrote:
>>> I have no idea why ptr_vector_*_type would behave differently here than
>>> build_pointer_type (vector_*_type_node). Using the build_pointer_type()
>>> fixed it for me, so that's
Hi Segher,
Gentle ping this patch as you wanted empty TU issue to be fixed
first at the discussion [1]. Thanks in advance for your time!
[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600927.html
BR,
Kewen
on 2022/7/25 14:26, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
&g
Hi!
> +
> + /* Use paddi for the low 32 bits. */
> + if (ud2 != 0 && ud1 != 0 && can_use_paddi)
> + emit_move_insn (dest, gen_rtx_PLUS (DImode, dest,
> + GEN_INT ((ud2 << 16) | ud1)));
> +
> + /* Use oris, ori for low 32 bits.
Hi,
As PR106833 shows, cv-qualified opaque type can cause ICE
during LTO. It exposes that we missd to handle OPAQUE_TYPE
well in type verification. As Richi pointed out, also
assuming that target will always define TYPE_MAIN_VARIANT
and TYPE_CANONICAL for opaque type, this patch is to check
both
Hi Richi,
Thanks for the review comments!
on 2022/9/8 15:36, Richard Biener wrote:
>
>
>> Am 08.09.2022 um 07:53 schrieb Kewen.Lin :
>>
>> Hi,
>>
>> As PR106833 shows, cv-qualified opaque type can cause ICE
>> during LTO. It exposes that we m
on 2022/9/9 15:25, Richard Biener wrote:
> On Fri, Sep 9, 2022 at 8:51 AM Kewen.Lin wrote:
>>
>> Hi Richi,
>>
>> Thanks for the review comments!
>>
>> on 2022/9/8 15:36, Richard Biener wrote:
>>>
>>>
>>>> Am 08.09.2022 um 07:
on 2022/4/26 11:25 PM, Segher Boessenkool wrote:
> On Tue, Apr 26, 2022 at 05:16:18PM +0200, Jakub Jelinek wrote:
>> Hi!
>>
>> On Fri, Apr 15, 2022 at 04:08:15PM +0800, Kewen.Lin via Gcc-patches wrote:
>>> As PR105271 shows, __builtin_altivec_neg_v2di requires opt
Hi,
As discussed in PR105334, this patch is to add the test coverage for
the two recent fixes r12-8091 and r12-8226 from Segher, aix is skipped
since it takes soft-float and long-double-128 incompatible.
I noticed the referred test case pack02.c skips if powerpc*-*-darwin*,
but it's for do-run an
on 2022/4/27 8:46 PM, David Edelsohn wrote:
> On Wed, Apr 27, 2022 at 8:22 AM Segher Boessenkool
> wrote:
>>
>> Hi!
>>
>> Thank you for doing this testcase.
>>
>> On Wed, Apr 27, 2022 at 06:29:07PM +0800, Kewen.Lin wrote:
>>> As discussed in P
Hi,
Add myself as PowerPC port co-maintainer and to DCO section. Pushed below as
r13-127.
ChangeLog:
* MAINTAINERS: Add myself as PowerPC port co-maintainer and to DCO
section.
---
MAINTAINERS | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b
on 2022/5/5 16:09, Richard Biener via Gcc-patches wrote:
> On Thu, May 5, 2022 at 10:07 AM HAO CHEN GUI via Gcc-patches
> wrote:
>>
>> Hi,
>>This patch skips constant folding for fmin/max when either argument
>> is sNaN. According to C standard,
>>fmin(sNaN, sNaN）= qNaN, fmin(sNaN, NaN) =
Hi Haochen,
Thanks for the patch, some comments are inlined.
on 2022/5/9 09:54, HAO CHEN GUI wrote:
> Hi,
> This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000.
> Tests show that outputs of xs[min/max]dp are consistent with the standard
> of C99 fmin/max.
>
> Bootstrapped
Hi Segher,
on 2022/5/10 20:27, Segher Boessenkool wrote:
> Hi guys,
>
> On Mon, May 09, 2022 at 12:05:51PM +0800, Kewen.Lin wrote:
>> on 2022/5/9 09:54, HAO CHEN GUI wrote:
>>> This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000.
>>> Tests s
on 2022/1/27 20:51, Segher Boessenkool wrote:
> On Thu, Jan 27, 2022 at 07:24:53PM +0800, Kewen.Lin wrote:
>> on 2022/1/27 上午1:57, Segher Boessenkool wrote:
>>> I like your original patch better. But for stage 1, sorry.
>>
>> Thanks Segher! Is it ok to commit it t
Hi Piotr,
Thanks for doing this, some comments are inlined.
on 2022/5/11 07:32, Piotr Kubaj via Gcc-patches wrote:
> Is there anything more required?
>
> On 22-05-03 12:33:43, Piotr Kubaj wrote:
>> Here are gmake check-gfortran results requested by FX.
>>
>> Before patching:
>> =
Hi Haochen,
on 2022/5/13 09:07, HAO CHEN GUI wrote:
> Hi,
>This patch adds a combine pattern for "CA minus one". As CA only has two
> values (0 or 1), we could convert following pattern
> (sign_extend:DI (plus:SI (reg:SI 98 ca)
> (const_int -1 [0x]
> t
on 2022/5/13 04:16, Segher Boessenkool wrote:
> Hi Piotr,
>
> On Tue, May 03, 2022 at 12:21:12PM +0200, pku...@freebsd.org wrote:
>> FreeBSD/powerpc* has feenableexcept() defined in fenv.h header.
>
> Declared, not defined. These are required to be real functions (on all
> platforms that have th
Hi,
PR105485 exposes that new builtin function framework doesn't handle
unresolved overloaded builtin function well. With new builtin
function support, we don't have builtin info for any overloaded
rs6000_gen_builtins enum, since they are expected to be resolved to
one specific instance. So when
Hi Haochen,
on 2022/5/16 13:22, HAO CHEN GUI wrote:
> Hi,
>This patch adds a combine pattern for "CA minus one". As CA only has two
> values (0 or 1), we could convert following pattern
> (sign_extend:DI (plus:SI (reg:SI 98 ca)
> (const_int -1 [0x]
> t
Hi,
As PR104482 shown, it's one regression about the handlings when
the argument number is more than the one of built-in function
prototype. The new bif support only catches the case that the
argument number is less than the one of function prototype, but
it misses the case that the argument numb
Hi,
As PR103353 shows, we may want to continue to expand a MMA built-in
function like a normal function, even if we have already emitted
error messages about some missing required conditions. As shown in
that PR, without one explicit mov optab on OOmode provided, it would
call emit_move_insn recu
Hi,
Move pr83660.C to g++.target. As comment #3 of PR83660,
renaming it to c isn't one option.
This test case isn't tested before, so this brings back
the test coverage.
Committed as r13-619-g297a69068ddfe2.
BR,
Kewen
-
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr83660.C: Move
Hi Piotr,
on 2022/5/23 05:36, Piotr Kubaj wrote:
> Ping.
>
> FreeBSD has already enabled sanitizers in its base system in
> https://cgit.freebsd.org/src/commit/?id=f5024381ac16ba43d37a8bd32d54c27f6a6afa66
> The upstream (LLVM) patch was reviewed by a couple of people already.
>
> Our llvm-devel
Hi,
Bootstrapped and regress-tested on powerpc64-linux-gnu P8 and
powerpc64le-linux-gnu P8, P9 and P10.
Pushed this as r13-720-g149d04ccbb908b3a251485b43faf204752942b9f.
---
As PR105627 exposes, pass analyze_swaps should skip debug
insn when doing unionfind_union. One debug insn can use
several
Hi,
Tested on powerpc64le-linux-gnu P8.
Pushed this as r13-721-g8fa8bca9f53fcfdedc2b4fa55093dbd1ab7abbd1.
BR,
Kewen
-
Commit r13-707 adjusts the below gimple:
iftmp.7_4 = _1 < _2 ? val2_7(D) : val1_8(D);
to
_3 = _1 >= _2;
iftmp.7_4 = _3 ? val1_8(D) : val2_7(D);
and result in one mo
Hi Richard,
Thanks a lot for the review and sorry for the late reply.
As the review comments, the changes against v2 are:
- Fix the introduced tabification issues in passes.def.
- Add pending TODOs group (different bitmask numbering).
- Move pending_TODOs unsigned to struct function.
- Fi
Hi,
Gentle ping for the patch:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553555.html
BR,
Kewen
on 2020/10/13 下午2:59, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> I'd like to gentle ping this patch:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-S
Hi,
Gentle ping^4 this:
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546698.html
BR,
Kewen
on 2020/10/13 下午3:06, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> Gentle ping this:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546698.html
>
> BR,
> Kewen
Hi Richard,
Thanks again for your review!
on 2020/11/2 下午6:23, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> diff --git a/gcc/function.c b/gcc/function.c
>> index 2c8fa217f1f..3e92ee9c665 100644
>> --- a/gcc/function.c
>> +++ b
Hi David,
Thanks for the review!
> The patch looks fine to me, but I'll let Segher decide if it addresses
> his requested changes.
>
> I'm trying to be stricter about the test cases.
>
> +++ b/gcc/testsuite/gcc.target/powerpc/pr96933-1.c
> @@ -0,0 +1,14 @@
> +/* { dg-do compile { target { lp64
Hi Lyon,
Thanks for reporting and sorry for the failure.
>> The patch was updated as your comments above, re-tested on Power8
>> and committed in r11-4637.
>>
>
> The new test gcc.dg/tree-ssa/pr96789.c fails on arm:
> FAIL: gcc.dg/tree-ssa/pr96789.c scan-tree-dump dse3 "Deleted dead store:.*tmp"
Hi Segher,
Thanks for the review!
>>> Why does this test has_arch_pwr9 instead of adding -mdejagnu-cpu=power9?
>>
>> I thought using -mdejagnu-cpu=power9 would force the case run with
>> power9 cpu all the time, while using has_arch_pwr9 seems to be more
>> flexible, it can be compiled with power
Hi,
As PR97705 shows, my commit r11-4637 caused some dumping
comparison difference error on pass ira. It exposed one
issue about the newly introduced function remove_scratches,
which can increase the largest pseudo reg number if it
succeeds, later some function will use the max_reg_num()
to get t
Hi Vladimir,
on 2020/11/6 下午10:49, Vladimir Makarov wrote:
>
> On 2020-11-06 1:15 a.m., Kewen.Lin wrote:
>> Hi,
>>
>> As PR97705 shows, my commit r11-4637 caused some dumping
>> comparison difference error on pass ira. It exposed one
>> issue about the newly
Hi,
As Lyon pointed out, the newly introduced test case
gcc.dg/tree-ssa/pr96789.c fails on arm-none-linux-gnueabihf.
Loop vectorizer is able to vectorize the two loops which
operate on array tmp with load_lanes feature support. It
makes dse3 get unexpected inputs and do nothing.
This patch is to
Hi Richard,
Thanks for the review!
on 2020/11/10 下午7:31, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi,
>>
>> As Lyon pointed out, the newly introduced test case
>> gcc.dg/tree-ssa/pr96789.c fails on arm-none-linux-gnueabihf.
>> Loop vectoriz
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 inlinable if callee_tree is
NULL, but it's wrong, we should use the command line options
from target_option_default_node as default.
Hi!
Option toc-fusion was intended for Power9 toc fusion previously,
but Power9 doesn't support fusion at all eventually, this patch
is to remove this useless option.
Is it ok for trunk?
BR,
Kewen
-
gcc/ChangeLog:
* config/rs6000/rs6000.opt (-mtoc-fusion): Remove.
---
gcc/config/rs
Hi!
Power ISA 2.07 (Power8) introduces transactional memory feature
but ISA3.1 (Power10) removes it. It exposes one troublesome
issue as PR102059 shows. Users define some function with
target pragma cpu=power10 then it calls one function with
attribute always_inline which inherits command line o
Hi Richi,
Thanks for the comments!
on 2021/9/2 下午5:25, Richard Biener wrote:
> On Wed, Sep 1, 2021 at 9:02 AM Kewen.Lin wrote:
>>
>> Hi!
>>
>> Power ISA 2.07 (Power8) introduces transactional memory feature
>> but ISA3.1 (Power10) removes it. It exposes one
on 2021/9/2 下午7:51, Richard Biener wrote:
> On Thu, Sep 2, 2021 at 1:13 PM Kewen.Lin wrote:
>>
>> Hi Richi,
>>
>> Thanks for the comments!
>>
>> on 2021/9/2 下午5:25, Richard Biener wrote:
>>> On Wed, Sep 1, 2021 at 9:02 AM Kewen.Lin wrote
Hi Segher,
Thanks for the comments!
on 2021/9/3 上午1:44, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Sep 01, 2021 at 03:02:22PM +0800, Kewen.Lin wrote:
>> It introduces two target hooks need_ipa_fn_target_info and
>> update_ipa_fn_target_info. The former allows target t
and got fixed by this
patch, besides got extra 3.93% speedup
against O2 and another bmk 554.roms_r got 3.24% speed up.
In short, the Power10 evaluation result shows this patch is positive.
> Otherwise I have one comment below...
>
> On 7/28/21 12:22 AM, Kewen.Lin wrote:
>> Hi,
>
Hi Segher,
Thanks for the comments!
on 2021/9/7 上午7:43, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Jul 28, 2021 at 10:59:50AM +0800, Kewen.Lin wrote:
>>>> +/* As a visitor function for each statement cost entry handled in
>>>> + function add_stmt_cost, gathe
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572555.html
BR,
Kewen
on 2021/7/15 上午10:00, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> Gentle ping this:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572555.html
>
> BR,
> Kewen
Hi!
Power ISA 2.07 (Power8) introduces transactional memory feature
but ISA3.1 (Power10) removes it. It exposes one troublesome
issue as PR102059 shows. Users define some function with
target pragma cpu=power10 then it calls one function with
attribute always_inline which inherits command line o
on 2021/9/8 下午2:57, Kewen.Lin via Gcc-patches wrote:
> Hi Bill,
>
> Thanks for the review comments!
>
> on 2021/9/3 下午11:57, Bill Schmidt wrote:
>> Hi Kewen,
>>
>> Sorry that we lost track of this patch! The heuristic approach looks good.
>> It is limite
Hi Segher and Bill,
Thanks a lot for your reviews and helps!
on 2021/9/10 上午1:19, Bill Schmidt wrote:
> On 9/9/21 11:11 AM, Segher Boessenkool wrote:
>> Hi!
>>
>> On Wed, Sep 08, 2021 at 02:57:14PM +0800, Kewen.Lin wrote:
>>>>> + /* If we have stride
on 2021/9/10 上午11:22, Kewen.Lin via Gcc-patches wrote:
> Hi Segher and Bill,
>
> Thanks a lot for your reviews and helps!
>
> on 2021/9/10 上午1:19, Bill Schmidt wrote:
>> On 9/9/21 11:11 AM, Segher Boessenkool wrote:
>>> Hi!
>>>
>>> On Wed, S
Hi,
This patch follows Segher's suggestion here[1] to get rid of
the typedef, it's pre-approved as [1].
Bootstrapped and regtested on powerpc64le-linux-gnu Power9.
Pushed to trunk as r12-3468.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579115.html
BR,
Kewen
-
gcc/ChangeL
mp; bif_no32bit_bit)
> #define bif_is_32bit(x) ((x).bifattrs & bif_32bit_bit)
> #define bif_is_cpu(x) ((x).bifattrs & bif_cpu_bit)
> #define bif_is_ldstmask(x) ((x).bifattrs & bif_ldstmask_bit)
> #define bif_is_lxvrse(x)((x).bifattrs & bif_lxvrs
Hi,
Gentle ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578553.html
BR,
Kewen
on 2021/9/1 下午2:56, Kewen.Lin via Gcc-patches wrote:
> Hi!
>
> Option toc-fusion was intended for Power9 toc fusion previously,
> but Power9 doesn't support fusion
Hi!
Gentle ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578552.html
BR,
Kewen
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, c
Hi,
This patch follows the discussion here[1], where Segher suggested
parameterizing those exact magic constants for density heuristics,
to make it easier to tweak if need.
Since these heuristics are quite internal, I make these parameters
as undocumented and be mainly used by developers.
The ch
Hi,
This patch follows the discussion here[1], where Segher pointed
out the existing way to guard the extra penalized cost for
strided/elementwise loads with a magic bound doesn't scale.
The way with nunits * stmt_cost can get one much exaggerated
penalized cost, such as: for V16QI on P8, it's 16
Hi Martin,
Thanks for the review comments!
on 2021/9/15 下午8:51, Martin Jambor wrote:
> Hi,
>
> since this is inlining-related, I would somewhat prefer Honza to have a
> look too, but I have the following comments:
>
> On Wed, Sep 08 2021, Kewen.Lin wrote:
>>
>
>
Hi!
Power ISA 2.07 (Power8) introduces transactional memory feature
but ISA3.1 (Power10) removes it. It exposes one troublesome
issue as PR102059 shows. Users define some function with
target pragma cpu=power10 then it calls one function with
attribute always_inline which inherits command line o
Hi,
When changing target_info with bitfield, I happened to find this
inconsistent streaming in and out. We have the streaming in:
bp_pack_value (&bp, info->inlinable, 1);
bp_pack_value (&bp, false, 1);
bp_pack_value (&bp, info->fp_expressions, 1);
while the streami
Hi Martin,
on 2021/9/16 下午9:19, Martin Jambor wrote:
> Hi,
>
> On Thu, Sep 16 2021, Kewen.Lin wrote:
>> Hi Martin,
>>
>> Thanks for the review comments!
>>
>> on 2021/9/15 下午8:51, Martin Jambor wrote:
>>> Hi,
>>>
>>> since
Hi Richi,
Thanks for the review!
on 2021/9/17 下午6:04, Richard Biener wrote:
> On Fri, Sep 17, 2021 at 12:03 PM Richard Biener
> wrote:
>>
>> On Fri, Sep 17, 2021 at 11:43 AM Kewen.Lin wrote:
>>>
>>> Hi,
>>>
>>> When changing target_info w
Hi Martin,
on 2021/9/17 下午7:26, Martin Jambor wrote:
> Hi,
>
> On Fri, Sep 17 2021, Kewen.Lin wrote:
>> on 2021/9/16 下午9:19, Martin Jambor wrote:
>>> On Thu, Sep 16 2021, Kewen.Lin wrote:
>>>> on 2021/9/15 下午8:51, Martin Jambor wrote:
>&g
Hi Bill,
Thanks for the review!
on 2021/9/18 上午12:34, Bill Schmidt wrote:
> Hi Kewen,
>
> On 9/15/21 8:14 PM, Kewen.Lin wrote:
>> Hi,
>>
>> This patch follows the discussion here[1], where Segher pointed
>> out the existing way to guard the extra penalized cost
Hi Segher,
Thanks for the review!
on 2021/9/18 上午6:01, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Sep 16, 2021 at 09:14:15AM +0800, Kewen.Lin wrote:
>> The way with nunits * stmt_cost can get one much exaggerated
>> penalized cost, such as: for V16QI on P8, it's 16 *
Hi Bill,
Thanks for the review!
on 2021/9/18 上午12:27, Bill Schmidt wrote:
> Hi Kewen,
>
> On 9/15/21 3:52 AM, Kewen.Lin wrote:
>> Hi,
>>
>> This patch follows the discussion here[1], where Segher suggested
>> parameterizing those exact magic constants for
on 2021/9/18 上午6:26, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Sep 15, 2021 at 04:52:49PM +0800, Kewen.Lin wrote:
>> This patch follows the discussion here[1], where Segher suggested
>> parameterizing those exact magic constants for density heuristics,
>> to make
Hi Segher,
Thanks for the review!
on 2021/9/17 下午10:14, Segher Boessenkool wrote:
> On Fri, Sep 17, 2021 at 05:42:38PM +0800, Kewen.Lin wrote:
>> Against v2 [2], this v3 addressed Martin's review comments:
>> - Replace HWI auto_vec with unsigned int for target_info
>
Hi Martin,
Thanks for the review.
on 2021/9/18 下午7:31, Martin Jambor wrote:
> Hi,
>
> On Fri, Sep 17 2021, Segher Boessenkool wrote:
>> On Fri, Sep 17, 2021 at 05:42:38PM +0800, Kewen.Lin wrote:
>>> Against v2 [2], this v3 addressed Martin's review comments:
>
on 2021/9/21 下午2:16, Richard Biener wrote:
> On Tue, Sep 21, 2021 at 4:09 AM Kewen.Lin wrote:
>>
>> Hi Richi,
>>
>> Thanks for the review!
>>
>> on 2021/9/17 下午6:04, Richard Biener wrote:
>>> On Fri, Sep 17, 2021 at 12:03 PM Richard Biener
>&g
on 2021/9/21 下午8:03, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Sep 21, 2021 at 01:47:19PM +0800, Kewen.Lin wrote:
>> on 2021/9/18 上午6:26, Segher Boessenkool wrote:
>>>> + if (data->nloads > (unsigned int) rs6000_density_load_num_threshold
>
on 2021/9/21 下午5:39, Richard Biener wrote:
> On Tue, Sep 21, 2021 at 11:31 AM Martin Jambor wrote:
>>
>> Hi,
>>
>> On Tue, Sep 21 2021, Kewen.Lin wrote:
>>> on 2021/9/17 下午7:26, Martin Jambor wrote:
>>>> On Fri, Sep 17 2021, Kewen.Lin wrote:
>&g
Hi,
As the discussion in PR102347, currently builtin_decl is invoked so
early, it's when making up the function_decl for builtin functions,
at that time the rs6000_builtin_mask could be wrong for those
builtins sitting in #pragma/attribute target functions, though it
will be updated properly later
Hi,
This patch follows the discussions here[1][2], where Segher
pointed out the existing way to guard the extra penalized
cost for strided/elementwise loads with a magic bound does
not scale.
The way with nunits * stmt_cost can get one much
exaggerated penalized cost, such as: for V16QI on P8, it
Hi Segher,
on 2021/9/23 上午6:36, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Sep 21, 2021 at 11:24:08AM +0800, Kewen.Lin wrote:
>> on 2021/9/18 上午6:01, Segher Boessenkool wrote:
>>> On Thu, Sep 16, 2021 at 09:14:15AM +0800, Kewen.Lin wrote:
>>>> The way with
on 2021/9/15 下午4:42, Kewen.Lin via Gcc-patches wrote:
> Hi!
>
> Gentle ping this patch:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578552.html
>
> BR,
> Kewen
>
> on 2021/9/1 下午2:55, Kewen.Lin via Gcc-patches wrote:
>> Hi!
>>
>>
king
time is too early right when the built-in function_decl being created.
BR,
Kewen
>
> My two cents,
> Bill
>
> On 9/28/21 3:13 AM, Kewen.Lin wrote:
>> Hi,
>>
>> As the discussion in PR102347, currently builtin_decl is invoked so
>> early, it's when m
Hi Bill,
on 2021/9/29 下午7:59, Bill Schmidt wrote:
> Hi Kewen,
>
> On 9/28/21 9:34 PM, Kewen.Lin wrote:
>> Hi Bill,
>>
>> Thanks for your prompt comments!
>>
>> on 2021/9/29 上午3:24, Bill Schmidt wrote:
>>> Hi Kewen,
>>>
>>> Althoug
Hi Robin,
on 2021/10/28 下午10:44, Robin Dapp wrote:
> Hi,
>
> as discussed in
> https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582627.html this
> introduces a bias parameter for the len_load/len_store ifns as well as
> optabs that is meant to distinguish between Power and s390 variants.
>
Hi Robin,
on 2021/11/3 上午4:16, Robin Dapp wrote:
> Hi,
>
> thanks for the helpful comments. The attached v2 addresses the following
> points from them:
>
> - Save the bias in loop_vinfo and set it once in vect_verify_loop_lens.
> - Add code to handle the bias in vect_set_loop_controls_directly
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!
&g
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
>>> point
>>>> 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
>>>&
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 th
Hi Qing,
on 2021/11/5 上午4:37, Qing Zhao via Gcc-patches wrote:
> Hi,
>
> I noticed that the macro “WIDE_INT_MAX_ELTS” has different values in GCC11
> and GCC12 (on the same X86 machine)
>
> For gcc11:
>
> wide int max elts =3
>
> For gcc12:
>
> wide int max elts =9
>
> Does anyone know what
Hi,
Commmit 5d9d0c94588 renamed future to power10 and ace60939fd2
updated the documentation for "future" renaming. This patch
is to rename the remaining "future architecture" references in
documentation.
Is it ok for trunk?
BR,
Kewen
-
gcc/ChangeLog:
* doc/invoke.texi: Change refer
Hi Segher,
on 2021/11/10 下午4:52, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Nov 10, 2021 at 01:41:25PM +0800, Kewen.Lin wrote:
>> Commmit 5d9d0c94588 renamed future to power10 and ace60939fd2
>> updated the documentation for "future" renaming. This patch
>&g
on 2021/11/10 下午6:03, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Nov 10, 2021 at 05:39:27PM +0800, Kewen.Lin wrote:
>> @@ -27779,10 +27779,10 @@ Enable/disable the @var{__float128} keyword for
>> IEEE 128-bit floating point
>> and use either software emulation for
Hi Eric,
on 2021/11/17 上午12:57, Eric Botcazou wrote:
>> gcc/ChangeLog:
>>
>> * config/visium/visium.md (*add3_insn, *addsi3_insn, *addi3_insn,
>> *sub3_insn, *subsi3_insn, *subdi3_insn, *neg2_insn,
>> *negdi2_insn, *and3_insn, *ior3_insn, *xor3_insn,
>> *one_cmpl2_insn, *ashl3_
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 50
>> for those statements in an inner loop relative to the loop being
>> ve
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,
>
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/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
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/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,
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
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
1001 - 1100 of 1615 matches
Mail list logo
