Hi,
Commit r12-2266 updated the scanned assembly content from
"{\mlvx\M|\mlxv\M|\mlxvd2x\M}"
to
"{\mp?lxv\M|\mlxv\M|\mlxvd2x\M}"
for the test case pr86731-fwrapv-longlong.c unexpectedly.
It's meant to update "lxv" to "p?lxv" and should leave the
"lvx" unchanged. So this is to fix the typ
Hi,
Test case bswap64-4.c suffers the issue as its comments:
/* On some versions of dejagnu this test will fail when
biarch testing with RUNTESTFLAGS="--target_board=unix
'{-m64,-m32}'" due to -m32 being added on the command
line after the dg-options -mpowerpc64.
common/config/rs6000/
Hi Segher & Peter,
Thanks for your reviews!
on 2022/8/31 23:12, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 05:33:21PM +0800, Kewen.Lin wrote:
>> It's meant to update "lxv" to "p?lxv" and should leave the
>> "lvx" unchanged. So this is to fix the typo accordingly.
>>
>> I'll push this so
+ if (TREE_TYPE (TREE_TYPE (src_ptr)) != src_type)
>>>
>>> This line looks unexpected, the former is type char while the latter is
>>> type __vector_pair *.
>>>
>>> I guess you meant to compare the type of pointer type like:
>>>
>>>TREE_TYPE (TREE_TYPE (src_ptr)) != TREE_TYPE (s
>>> ...and of course, now I can't recreate that issue at all and the
>>> ptr_vector_*_type use work fine now. Strange! ...so ok, changed.
>>> Maybe the behavior changed since my PR106017 fix went in???
>>
>> That is my best guess as well. But, how did that help this test?
>
> It didn't. :-) Du
on 2022/8/31 22:13, Peter Bergner wrote:
> On 8/31/22 4:33 AM, Kewen.Lin wrote:
>> @@ -1,7 +1,8 @@
>> /* { dg-do compile { target { powerpc*-*-* } } } */
>> /* { dg-skip-if "" { powerpc*-*-aix* } } */
>> -/* { dg-options "-O2 -mpowerpc64" } */
>> /* { dg-require-effective-target ilp32 } */
>> +/
Hi Segher and Peter,
Thanks a lot for your insightful comments on this.
I just read through all discussions and plan to give a
try as replied below.
on 2022/8/31 23:24, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 05:33:28PM +0800, Kewen.Lin wrote:
>> Test case bswap64-4.c suffers the iss
Hi Haochen,
on 2022/9/1 13:30, HAO CHEN GUI wrote:
> Hi,
> This patch changes the sequence of test directives for 3 test cases.
> Originally, these 3 cases got failed or unsupported on some platforms, as
> their effective target checks depend on compiling options.
>
Thanks for the updated patc
Hi Segher,
on 2022/9/1 22:57, Segher Boessenkool wrote:
> On Thu, Sep 01, 2022 at 04:57:59PM +0800, Kewen.Lin wrote:
>> on 2022/8/31 22:13, Peter Bergner wrote:
>>> On 8/31/22 4:33 AM, Kewen.Lin wrote:
@@ -1,7 +1,8 @@
/* { dg-do compile { target { powerpc*-*-* } } } */
/* { dg-ski
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 disable -mpowerpc64 at -m32 is that we ha
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?
>>
>> If yes, it looks we don't n
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 some cases -- the test will not
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-), I think we all agree
that
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 why I went with it. :-) Maybe this i
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 missd to handle OPAQUE_TYPE
>> well in type verifica
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:53 schrieb Kewen.Lin :
Hi,
As PR106833 shows, cv-qua
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 PR105334, this patch is to add the test coverage for
>>>
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 show that outputs of xs[min/max]dp
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 then? Or I'll repost this once
>>
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/gcc/function.c
>> @@ -4841,6 +4841,8 @@ allocate_struct_function
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 introduced function remove_scratches,
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 vectorizer is able to vectorize the two loops which
>>
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 troublesome
>> issue as PR102059 show
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!
Power ISA 2.07 (Power8) introduces
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 to do
>> some previous chec
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 limited in scope and won't kick in often, and the case you're trying to
> account for is important.
>
> At the
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, gather some information and update its
>
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 strided or elementwise loads into a vector, it's
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
Hi Bill,
on 2021/9/13 上午12:34, Bill Schmidt wrote:
> Hi Kewen,
>
> I'll leave the continued review of the back-end parts of this to Segher, but
> I do have one long-term comment. The rs6000_builtin_info[code].mask field
> that you're relying on is going away as part of the built-in function
>
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:
>>
>
> [...]
>
>> diff --git a/gcc/ip
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 this is inlining-related, I would somewhat prefer Honza to have a
>>> look
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 with bitfield, I happened to find this
>>> inconsistent st
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:
> On Wed, Sep 08 2021, Kewen.Lin wrote:
>>
>
>
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 for
>> strided/elementwise loads w
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 * 20 = 320,
>> that's why we
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 density heuristics,
>> to make it easier
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 it easier to tweak if need.
>>
>
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
>> to avoid overkill (als
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:
>>> - Replace HWI auto_vec with uns
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
>>> wrote:
On Fri, Sep 17, 2021 at 11:43 AM Kew
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
+&& load_pct > (unsigned int) rs6000_densit
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:
>> [...]
>
> Sorry that I failed to use 16 bit-f
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 nunits * stmt_cost can get one much exa
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!
>>
>>
Hi Bill,
Thanks for your prompt comments!
on 2021/9/29 上午3:24, Bill Schmidt wrote:
> Hi Kewen,
>
> Although I agree that what we do now is tragically bad (and will be fixed in
> the builtin rewrite), this seems a little too cavalier to remove all checking
> during initialization without adding
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,
>>>
>>> Although I agree that what we do now is tragically bad (and will be fixed
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
>> is to rename the remaining "future ar
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 IEEE 128-bit floating point or
401 - 500 of 1024 matches
Mail list logo
