Hi Iain,
Thanks again for your help!!
on 2022/9/29 16:16, Iain Sandoe wrote:
> Hi Kewen,
>
> thanks for looking at this!
> (I suspect it would also affect a 32b linux host with a 64b multilib)
>
Quite reasonable suspicion.
> quite likely powerpc-darwin is the only 32b ppc host in regular test
Hi Segher!
Thanks for the review comments!!
on 2022/9/29 06:04, Segher Boessenkool wrote:
> On Wed, Sep 28, 2022 at 01:30:46PM +0800, Kewen.Lin wrote:
>> PR106680 shows that -m32 -mpowerpc64 is different from
>> -mpowerpc64 -m32, this is determined by the way how we
>> handl
7:37, Iain Sandoe wrote:
>>
>>>> On 28 Sep 2022, at 06:30, Kewen.Lin via Gcc-patches
>>>> wrote:
>>>
>>>> PR106680 shows that -m32 -mpowerpc64 is different from
>>>> -mpowerpc64 -m32, this is determined by the way how we
>>>>
on 2022/8/29 14:35, Kewen.Lin via Gcc-patches wrote:
> on 2022/8/15 16:33, Kewen.Lin via Gcc-patches wrote:
>> on 2022/7/11 11:42, Kewen.Lin wrote:
>>> on 2022/6/15 14:20, Kewen.Lin wrote:
>>>> Hi Honza,
>>>>
>>>> Thanks for the comments! Som
Hi,
Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600190.html
BR,
Kewen
on 2022/8/24 16:17, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As discussed in PR98125, -fpatchable-function-entry with
> SECTION_LINK_ORDER support doesn't work well on powerpc64
&g
Hi,
Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600277.html
BR,
Kewen
on 2022/8/25 13:50, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As PR99888 and its related show, the current support for
> -fpatchable-function-entry on powerpc ELFv2 doesn't work
&
Hi,
I assumed the generic part introducing check_effective_target_vect_int_mod
needs the approval from global maintainers.
So gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600191.html
BR,
Kewen
on 2022/8/24 16:17, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As
Hi,
PR106680 shows that -m32 -mpowerpc64 is different from
-mpowerpc64 -m32, this is determined by the way how we
handle option powerpc64 in rs6000_handle_option.
Segher pointed out this difference should be taken as
a bug and we should ensure that option powerpc64 is
independent of -m32/-m64. S
Hi Jeff,
on 2022/9/7 15:08, Jiufu Guo via Gcc-patches wrote:
> Hi,
>
> As the issue in PR106460, a rtx 'high:DI (symbol_ref:DI ("var_48")' is tried
> to store into constant pool and ICE occur. But actually, this rtx represents
> partial address and can not be put into a .rodata section.
>
> Thi
Hi Segher,
on 2022/9/22 22:05, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Sep 22, 2022 at 10:28:23AM +0800, Kewen.Lin wrote:
>> on 2022/9/22 05:56, Segher Boessenkool wrote:
>>> On Fri, Jun 24, 2022 at 10:02:19AM +0800, HAO CHEN GUI wrote:
>>> In the othe
Hi Segher,
Thanks for the comments!
on 2022/9/23 06:13, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Sep 22, 2022 at 09:41:42AM +0800, Kewen.Lin wrote:
>> * config/rs6000/rs6000-logue.cc (rs6000_emit_epilogue): Update the
>> condition for adding REG_CFA_
Hi Segher,
Thanks for the comments!
on 2022/9/23 05:39, Segher Boessenkool wrote:
> Hi!
>
> Heh, I first thought I had mistyped thgew PR #, but it is this one after
> all :-)
>
> On Thu, Sep 22, 2022 at 09:41:34AM +0800, Kewen.Lin wrote:
>> PR100645 exposes one lat
on 2022/9/22 05:56, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Jun 24, 2022 at 10:02:19AM +0800, HAO CHEN GUI wrote:
>> This patch also binds __builtin_vsx_xs[min/max]dp to fmin/max instead
>> of smin/max. So the builtins always generate xs[min/max]dp on all
>> platforms.
>
> But how does this
Hi,
As PR96072 shows, the code adding REG_CFA_DEF_CFA reg note
makes one assumption that we have emitted one insn which
restores the frame pointer previously. That part of code
was guarded with flag frame_pointer_needed before, it was
consistent, but later it was replaced with flag
frame_pointer_
Hi,
PR100645 exposes one latent bug in define_expand vec_shr_
that the current condition TARGET_ALTIVEC is too loose. The
mode iterator VEC_L contains a few modes, they are not always
supported as vector mode, VECTOR_UNIT_ALTIVEC_OR_VSX_P should
be used like some other VEC_L usages.
Bootstrappe
Hi Haochen,
on 2022/6/24 10:02, 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.
>
> This patch also binds __builtin_vsx_xs[min/max]dp to fmin/max
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:
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
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!
> +
> + /* 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 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
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
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/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/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
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
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 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 { ta
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 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 su
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"
>>> ...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
+ 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
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 thi
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,
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 Peter,
Thanks for the patch! Some comments are inline as below.
on 2022/8/27 11:50, Peter Bergner via Gcc-patches wrote:
> When we expand an MMA disassemble built-in with C++ using a pointer that
> is casted to a valid MMA type, the type isn't passed down to the expand
> machinery and we end
on 2022/8/15 16:33, Kewen.Lin via Gcc-patches wrote:
> on 2022/7/11 11:42, Kewen.Lin wrote:
>> on 2022/6/15 14:20, Kewen.Lin wrote:
>>> Hi Honza,
>>>
>>> Thanks for the comments! Some replies are inlined below.
>>>
>>> on 2022/6/14 19
Hi,
Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595208.html
I think this is a reasonable fix, the behavior is consistent with what we have
in
the previous built-in framework, I'm going to push this a week later if no
objections. :)
BR,
Kewen
> Hi,
>
> As PR104
gt;> on 2022/5/13 13:29, Kewen.Lin via Gcc-patches wrote:
>>>>> Hi,
>>>>>
>>>>> PR105485 exposes that new builtin function framework doesn't handle
>>>>> unresolved overloaded builtin function well. With new builtin
>>>>
Hi,
Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598601.html
BR,
Kewen
>
> on 2022/7/20 17:30, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> Commit r12-6679-g7ca1582ca60dc8 made vectorizer accept one
>> unroll factor to be applied to vectorizat
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598748.html
BR,
Kewen
> on 2022/7/25 14:26, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> As the failure of test case gcc.target/powerpc/pr92398.p9-.c in
>> PR106345 shows, some test sources
Hi Haochen,
on 2022/8/26 15:29, HAO CHEN GUI wrote:
> Hi,
> This patch changes the sequence of test directives for 3 cases. Originally,
> these 3 cases got failed or unsupported on some platforms, as their target
> selector checks depend on compiling options.
Maybe it's good to say more in the
on 2022/8/26 10:42, HAO CHEN GUI wrote:
> Hi David,
>
> On 25/8/2022 下午 10:01, David Edelsohn wrote:
>> On Thu, Aug 25, 2022 at 1:22 AM Kewen.Lin wrote:
>>>
>>> on 2022/8/25 11:37, HAO CHEN GUI wrote:
>>>> Hi,
>>>>
>>>> On 24
on 2022/8/24 22:01, Segher Boessenkool wrote:
> On Wed, Aug 24, 2022 at 03:30:51PM +0800, Kewen.Lin wrote:
>> on 2022/8/23 22:33, Segher Boessenkool wrote:
>> I thought if we can consider [1] and updated the documentation similarly
>> like "For PowerPC with the ELFv2
Hi,
As PR99888 and its related show, the current support for
-fpatchable-function-entry on powerpc ELFv2 doesn't work
well with global entry existence. For example, with one
command line option -fpatchable-function-entry=3,2, it got
below w/o this patch:
.LPFE1:
nop
nop
on 2022/8/25 11:37, HAO CHEN GUI wrote:
> Hi,
>
> On 24/8/2022 下午 1:24, Kewen.Lin wrote:
>> Could you try to test with dg-options "-mdejagnu-cpu=power9 -mpowerpc64" all
>> the time, but still
>> having that has_arch_ppc64 effective target on aix?
>>
&g
Hi,
As PR106516 shows, we can get unexpected gimple outputs for
function thud on some target which supports modulus operation
for vector int. This patch introduces one effective target
vect_int_mod for it, then adjusts the test case with it.
Tested on x86_64-redhat-linux and powerpc64{,le}-linux
Hi,
As discussed in PR98125, -fpatchable-function-entry with
SECTION_LINK_ORDER support doesn't work well on powerpc64
ELFv1 because the filled "Symbol" in
.section name,"flags"o,@type,Symbol
sits in .opd section instead of in the function_section
like .text or named .text*.
Since we already
Hi Segher,
on 2022/8/23 22:33, Segher Boessenkool wrote:
> On Fri, Aug 19, 2022 at 10:40:10AM +0800, Kewen.Lin wrote:
>> Since you proposed to update the documentation, I'm thinking if we can
>> reconsider Fangrui's proposal in the PR which Alan seconded: Put precedi
on 2022/8/24 13:11, HAO CHEN GUI wrote:
> Hi Segher,
>
> On 23/8/2022 下午 10:26, Segher Boessenkool wrote:
>> Hi!
>>
>> On Fri, Aug 19, 2022 at 10:35:54AM +0800, HAO CHEN GUI wrote:
>>> --- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-0.c
>>> +++ b/gcc/testsuite/gcc.target/powerpc/bfp/
Hi Haochen,
on 2022/8/19 10:35, HAO CHEN GUI wrote:
> Hi,
>
> This patch is for internal issue1136. It changes insn condition from
> TARGET_64BIT to TARGET_POWERPC64 for VSX scalar extract/insert instructions.
> These instructions all use DI registers and can be invoked with -mpowerpc64
> in a
Hi Segher,
Thanks for the review!
on 2022/8/19 01:34, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Aug 18, 2022 at 10:12:48AM +0800, Kewen.Lin wrote:
>> As PR99888 and its related show, the current support for
>> -fpatchable-function-entry on powerpc ELFv2 doesn't work
Hi,
As PR99888 and its related show, the current support for
-fpatchable-function-entry on powerpc ELFv2 doesn't work
well with global entry existence. For example, with one
command line option -fpatchable-function-entry=3,2, it got
below w/o this patch:
.LPFE1:
nop
nop
Hi Xionghu,
Thanks for the updated version of patch, some comments are inlined.
on 2022/8/11 14:15, Xionghu Luo wrote:
>
>
> On 2022/8/11 01:07, Segher Boessenkool wrote:
>> On Wed, Aug 10, 2022 at 02:39:02PM +0800, Xionghu Luo wrote:
>>> On 2022/8/9 11:01, Kewen.Lin
Hi Segher,
Thanks for the review!
on 2022/8/16 05:30, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jun 27, 2022 at 10:47:26AM +0800, Kewen.Lin wrote:
>> on 2022/6/25 00:49, Segher Boessenkool wrote:
>> Many thanks for all the further explanation above! The attached
on 2022/7/11 11:42, Kewen.Lin wrote:
> on 2022/6/15 14:20, Kewen.Lin wrote:
>> Hi Honza,
>>
>> Thanks for the comments! Some replies are inlined below.
>>
>> on 2022/6/14 19:37, Jan Hubicka wrote:
>>>> Hi,
>>>>
>>>> Function opt
Hi,
Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597286.html
BR,
Kewen
>
> on 2022/6/27 10:47, Kewen.Lin via Gcc-patches wrote:
>> Hi Segher!
>>
>> on 2022/6/25 00:49, Segher Boessenkool wrote:
>>> Hi!
>>>
>>> On Fri
Hi,
Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595208.html
BR,
Kewen
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 cas
Hi,
Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594699.html
BR,
Kewen
>>
>>> on 2022/5/13 13:29, Kewen.Lin via Gcc-patches wrote:
>>>> Hi,
>>>>
>>>> PR105485 exposes that new builtin function framework doesn't handle
>
Hi,
Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598601.html
BR,
Kewen
on 2022/7/20 17:30, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> Commit r12-6679-g7ca1582ca60dc8 made vectorizer accept one
> unroll factor to be applied to vectorization factor when
> vecto
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598748.html
BR,
Kewen
on 2022/7/25 14:26, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As the failure of test case gcc.target/powerpc/pr92398.p9-.c in
> PR106345 shows, some test sources for some power
Hi Richi,
>>
>> Yes, but you just missed the RC for 12.2 so please wait until after GCC 12.2
>> is released and the branch is open again. The testcase looks mightly
>> complicated
>> so fallout there might be well possible as well ;) I suppose it wasn't
>> possible
>> to craft a simple C testca
on 2022/8/12 19:14, Richard Biener wrote:
> On Fri, Aug 12, 2022 at 11:41 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> As PR106322 shows, in some cases for some vector type whose
>> TYPE_MODE is a scalar integral mode instead of a vector mode,
>> it's possibl
Hi Jeff,
on 2022/8/12 14:39, Jiufu Guo via Gcc-patches wrote:
> Hi,
>
> As a comment in
> https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599556.html
>
> Those splitters call rs6000_emit_set_const directly, and the replacements
> are never used. Using (pc) would be less misleading.
Since
Hi,
As PR106322 shows, in some cases for some vector type whose
TYPE_MODE is a scalar integral mode instead of a vector mode,
it's possible to obtain wrong target support information when
querying with the scalar integral mode. For example, for the
test case in PR106322, on ppc64 32bit vectorizer
Hi,
As PR99888 and its related show, the current support for
-fpatchable-function-entry on powerpc ELFv2 doesn't work
well with global entry existence. For example, with one
command line option -fpatchable-function-entry=3,2, it got
below w/o this patch:
.LPFE1:
nop
nop
on 2022/8/10 05:10, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Aug 09, 2022 at 08:51:59PM +0800, Kewen.Lin wrote:
>> on 2022/8/9 18:35, Segher Boessenkool wrote:
>>>> +/* As ELFv2 ABI shows, the allowable bytes past the global entry
>>>> + point a
on 2022/8/10 05:34, Segher Boessenkool wrote:
> On Tue, Aug 09, 2022 at 11:14:16AM +0800, Kewen.Lin wrote:
>> on 2022/8/8 14:04, HAO CHEN GUI wrote:
>>> +/* { dg-do run { target { has_arch_ppc64 } } } */
>>> +/* { dg-options "-O2 -mdejagnu-cpu=power9 -save-
Hi Segher,
Thanks for the review comments!
on 2022/8/9 18:35, Segher Boessenkool wrote:
> Hi!
>
>> + /* As ELFv2 ABI shows, the allowable bytes past the global entry
>> + point are 0, 4, 8, 16, 32 and 64. Considering there are two
>> + non-prefixed instructions for global e
Hi,
r10-631 had renamed rs6000_global_entry_point_needed_p to
rs6000_global_entry_point_prologue_needed_p. This is to
remove the stale function declaration.
Bootstrapped and regtested on powerpc64-linux-gnu P8 and
powerpc64le-linux-gnu P9 and P10.
I'll push this soon.
BR,
Kewen
-
gcc/Chang
Hi,
In function rs6000_init_builtins, there is a oversight that
in one target debugging hunk with TARGET_DEBUG_BUILTIN we
missed to handle enum bif_enable ENB_CELL. It's easy to
fix it by adding another if case. But considering the long
term maintainability, this patch updates it with the existi
Hi,
As PR99888 and its related show, the current support for
-fpatchable-function-entry on powerpc ELFv2 doesn't work
well with global entry existence. For example, with one
command line option -fpatchable-function-entry=3,2, it got
below w/o this patch:
.LPFE1:
nop
nop
Hi Haochen,
Thanks for the patch.
on 2022/8/8 14:04, HAO CHEN GUI wrote:
> Hi,
> This patch adds an expand and several insns for multiply-add with three
> 64bit operands.
>
> Compared with last version, the main changes are:
> 1 The "maddld" pattern is reused for the low-part generation.
> 2
Hi Xionghu,
Thanks for the fix.
on 2022/8/8 11:42, Xionghu Luo wrote:
> The native RTL expression for vec_mrghw should be same for BE and LE as
> they are register and endian-independent. So both BE and LE need
> generate exactly same RTL with index [0 4 1 5] when expanding vec_mrghw
> with vec_
Hi Haochen,
on 2022/8/4 17:55, HAO CHEN GUI wrote:
> Hi,
> This patch corrects return value of check_p9modulo_hw_available. It should
> return 0 when p9modulo is supported.
Good catch! There is no case using p9modulo_hw for now, no coverage, sigh...
>
> Bootstrapped and tested on powerpc64
Hi Haochen,
on 2022/8/3 16:24, HAO CHEN GUI wrote:
> Hi,
> This patch changes the definition of TARGET_MADDLD and includes
> TARGET_POWERPC64, since maddld is a 64 bit instruction.
>
> maddld-1.c now checks "has_arch_ppc64". It depends on a patch which fixes
> empty TU problem.
> https://gcc.
Hi Haochen,
Thanks for the patch, some comments are inlined.
on 2022/7/25 13:11, HAO CHEN GUI wrote:
> Hi,
> This patch adds an expand and several insns for multiply-add with
> three 64bit operands.
>
> Bootstrapped and tested on powerpc64-linux BE and LE with no regressions.
> Is this okay
Hi,
Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597286.html
BR,
Kewen
on 2022/6/27 10:47, Kewen.Lin via Gcc-patches wrote:
> Hi Segher!
>
> on 2022/6/25 00:49, Segher Boessenkool wrote:
>> Hi!
>>
>> On Fri, Jun 24, 2022 at 09:03:59AM +0800, Kewen.
Hi,
Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595208.html
BR,
Kewen
>>> 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 tha
Hi,
Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594699.html
BR,
Kewen
>
>> on 2022/5/13 13:29, Kewen.Lin via Gcc-patches wrote:
>>> Hi,
>>>
>>> PR105485 exposes that new builtin function framework doesn't handle
>>> unre
Hi Jeff,
on 2022/7/19 22:30, Jiufu Guo wrote:
> Hi,
>
> In patch https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597712.html,
> test case was not added. After more check, a testcase is added for it.
>
Good to see that you constructed one actual test case, nice! :)
> The high part of the
Hi,
As the failure of test case gcc.target/powerpc/pr92398.p9-.c in
PR106345 shows, some test sources for some powerpc effective
targets use empty translation unit wrongly. The test sources
could go with options like "-ansi -pedantic-errors", then those
effective target checkings will fail unexpe
Hi Peter and Segher,
on 2022/7/23 03:28, Peter Bergner wrote:
> On 7/22/22 1:53 PM, Peter Bergner wrote:
>> So I think the way the code above *should* work is:
>> 1) Any -mdejagnu-cpu= usage should filter out all -mcpu= and -mtune=
>> options.
>> 2) Any -mdejagnu-tune= usage should filter all
Hi Segher,
Thanks for the comments!
on 2022/7/22 02:48, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Jul 20, 2022 at 05:31:11PM +0800, Kewen.Lin wrote:
>> As PR106345 shows, some test cases should be updated with
>> -mdejagnu-tune, since their test points are sensitive to
&g
Hi!
on 2022/7/22 09:02, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Jul 22, 2022 at 08:41:43AM +0800, Kewen.Lin wrote:
>> Hi Segher,
>>
>> Thanks for the comments!
>
> Always.
>
>>>> This patch is to fix empty TUs with one dummy variable defin
Hi Segher,
Thanks for the comments!
on 2022/7/22 06:09, Segher Boessenkool wrote:
> On Wed, Jul 20, 2022 at 05:32:01PM +0800, Kewen.Lin wrote:
>> As the failure of test case gcc.target/powerpc/pr92398.p9-.c in
>> PR106345 shows, some test sources for some powerpc effective
>&
Hi Richi,
on 2022/7/21 17:01, Richard Biener via Gcc-patches wrote:
> The following teaches VN to handle reads from .MASK_STORE and
> .LEN_STORE. For this push_partial_def is extended first for
> convenience so we don't have to handle the full def case in the
> caller (possibly other paths can be
Hi,
As PR106345 shows, some test cases should be updated with
-mdejagnu-tune, since their test points are sensitive to
rs6000_tune, such as: group_ending_nop, loop align (ic),
float conversion cost etc.
This patch is to replace -mdejagnu-cpu with -mdejagnu-tune
or append -mdejagnu-tune (keep the
Hi,
As the failure of test case gcc.target/powerpc/pr92398.p9-.c in
PR106345 shows, some test sources for some powerpc effective
targets use empty translation unit wrongly. The test sources
could go with options like "-ansi -pedantic-errors", then those
effective target checkings will fail unexpe
Hi,
Commit r12-6679-g7ca1582ca60dc8 made vectorizer accept one
unroll factor to be applied to vectorization factor when
vectorizing the main loop, it would be suggested by target
when doing costing.
This patch introduces function determine_suggested_unroll_factor
for rs6000 port, to make it be ab
Hi Will,
on 2022/7/20 04:15, will schmidt wrote:
> [PATCH, rs6000, v2] Additional cleanup of rs6000_builtin_mask
>
> Hi,
> Post the rs6000 builtins rewrite, some of the leftover builtin
> code is redundant and can be removed.
> This replaces the usage of bu_mask in rs6000_target_modify_ma
Hi Will,
Thanks for the cleanup! Some comments are inlined.
on 2022/7/14 05:39, will schmidt wrote:
> [PATCH, rs6000] Additional cleanup of rs6000_builtin_mask
>
> Hi,
> Post the rs6000 builtins rewrite, some of the leftover builtin
> code is redundant and can be removed.
> This replace
Hi Jeff,
Thanks for the patch, one question is inlined below.
on 2022/7/4 14:58, Jiufu Guo wrote:
> The high part of the symbol address is invalid for the constant pool. In
> function rs6000_cannot_force_const_mem, we already return true for
> "HIGH with UNSPEC" rtx. During debug GCC, I found tha
on 2022/6/15 14:20, Kewen.Lin wrote:
> Hi Honza,
>
> Thanks for the comments! Some replies are inlined below.
>
> on 2022/6/14 19:37, Jan Hubicka wrote:
>>> Hi,
>>>
>>> Function optimize_function_for_size_p returns OPTIMIZE_SIZE_NO
>>> if fun
on 2022/7/8 19:37, Martin Liška wrote:
> On 6/6/22 08:20, Kewen.Lin wrote:
>> |Hi, PR105459 exposes one issue in inline_call handling that when it decides
>> to copy FP flags from callee to caller and rebuild the optimization node for
>> caller fndecl, it's possible t
Hi Roger,
on 2022/7/8 03:40, Roger Sayle wrote:
>
> Hi Kewen (and Segher),
> Many thanks for stress testing my patch to improve multiplication
> by integer constants on rs6000 by using the rldmi instruction.
> Although I've not been able to reproduce your ICE (using gcc135
> on the compile farm),
on 2022/7/7 17:03, Richard Biener wrote:
> On Thu, Jul 7, 2022 at 10:55 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> As test case in PR106091 shows, rs6000 specific pass swaps
>> doesn't preserve the reg_note REG_EH_REGION when replacing
>> some load insn at t
Hi,
As test case in PR106091 shows, rs6000 specific pass swaps
doesn't preserve the reg_note REG_EH_REGION when replacing
some load insn at the end of basic block, it causes the
flow info verification to fail unexpectedly. Since memory
reference rtx may trap, this patch is to ensure we copy
REG_
Hi Richi,
Thanks for the insightful comments!
on 2022/7/1 16:40, Richard Biener wrote:
> On Thu, Jun 23, 2022 at 4:03 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596212.html
>>
>> BR,
>> Kew
801 - 900 of 1474 matches
Mail list logo
