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.
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
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
t; 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
>>>>> funct
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/8/2022 下午 1:24, Kewen.Lin wrote:
> Could you try to test with
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 ABI, there will be M nops
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?
>>
>> I'd expect has_arch_ppc64 check to fail on
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
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 preceding
>> nops before GEP and
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
>>> +++
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
>> well with global entry
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 wrote:
I have some
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 patch
>> updated the
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 optimize_function_for_size_p returns OPTIMIZE_SIZE_NO
if func->decl
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
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
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 possible to obtain wrong target support information
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.
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
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 are 0, 4, 8, 16, 32 and 64. Considering
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-temps" } */
>>> +/* {
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
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
-
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
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.
>
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
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
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.
>
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
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
>>> unresolve
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
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
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
>> rs6000_tune, such
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 definition
accordingly.
>>>
>>> You can also use
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
>> targets use empty
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
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
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
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
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
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
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 func->decl is not null but no cgraph node is available
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 that the target option node
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
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 the end of basic block, it causes the
>> flow
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
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
Hi Segher!
on 2022/6/28 00:02, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jun 27, 2022 at 05:35:03PM +0800, Kewen.Lin wrote:
>> -(define_insn "*rotl3_insert_4"
>> - [(set (match_operand:GPR 0 "gpc_reg_operand" "=r")
>> -(ior:GPR (and:GPR (match_operand:GPR 3 "gpc_reg_operand" "0")
>> -
Hi Roger,
on 2022/6/27 04:56, Roger Sayle wrote:
>
>
> This patch tweaks the code generated on POWER for integer multiplications
>
> by a constant, by making use of rldimi instructions. Much like x86's
>
> lea instruction, rldimi can be used to implement a shift and add pair
>
> in some
Hi,
define_insn *rotl3_insert_4 use mode iterator GPR which
consists of SImode and conditional DImode, but the condition
of this define_insn requires the mode should be SImode. By
further checking, it's found that the rldimi instruction can
not be used for this pattern since the required mask
Hi Segher!
on 2022/6/25 00:49, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Jun 24, 2022 at 09:03:59AM +0800, Kewen.Lin wrote:
>> on 2022/6/24 03:06, Segher Boessenkool wrote:
>>> On Wed, May 18, 2022 at 10:07:48PM +0800, Kewen.Lin wrote:
As PR103353 shows, we may want to continue to expand
Hi Segher,
Thanks for the comments.
on 2022/6/24 03:06, Segher Boessenkool wrote:
> Hi!
>
> On Wed, May 18, 2022 at 10:07:48PM +0800, Kewen.Lin wrote:
>> 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
>>
Hi,
Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596212.html
BR,
Kewen
on 2022/6/6 14:20, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> PR105459 exposes one issue in inline_call handling that when it
> decides to copy FP flags from callee to caller
Hi,
Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595209.html
BR,
Kewen
>> 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.
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 that
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
>> unresolved overloaded builtin funct
on 2022/6/21 06:10, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Jun 17, 2022 at 07:13:37AM +0200, Roger Sayle wrote:
>> This patch addresses PR target/105991 where a change to prefer representing
>> shifts and adds at the tree-level as multiplications, causes problems for
>> the rldimi patterns
on 2022/6/20 15:47, Richard Biener wrote:
> On Fri, Jun 17, 2022 at 12:53 PM Kewen.Lin wrote:
>>
>> Hi,
>>
>> This follows Richi's suggestion in PR105940, it aims to avoid
>> inconsistent slp decision between when the suggested unroll
>> factor is worked out and when the suggested unroll factor
Hi,
This follows Richi's suggestion in PR105940, it aims to avoid
inconsistent slp decision between when the suggested unroll
factor is worked out and when the suggested unroll factor is
applied.
If the previous slp decision is true when the suggested unroll
factor is worked out, when we are
on 2022/6/14 20:53, Segher Boessenkool wrote:
> On Tue, Jun 14, 2022 at 03:57:08PM +0800, Kewen.Lin wrote:
>> PR target/105818
>
> Change this to something else? It is not a target bug. "middle-end"
> perhaps?
>
Good catch, will fix this. Thanks Segher!
BR,
Kewen
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 func->decl is not null but no cgraph node is available for it.
>> As PR105818 shows, this could give
Hi,
Function optimize_function_for_size_p returns OPTIMIZE_SIZE_NO
if func->decl is not null but no cgraph node is available for it.
As PR105818 shows, this could give unexpected result. For the
case in PR105818, when parsing bar decl in function foo, the cfun
is a function structure for foo,
on 2022/6/13 19:38, Richard Biener wrote:
> On Mon, Jun 13, 2022 at 12:02 PM Kewen.Lin wrote:
>>
>> Hi,
>>
>> As PR105940 shown, when rs6000 port tries to assign
>> m_suggested_unroll_factor by 4 or so, there will be ICE
>> on below statement:
>>
>> exact_div (LOOP_VINFO_VECT_FACTOR
Hi,
As PR105940 shown, when rs6000 port tries to assign
m_suggested_unroll_factor by 4 or so, there will be ICE
on below statement:
exact_div (LOOP_VINFO_VECT_FACTOR (loop_vinfo),
loop_vinfo->suggested_unroll_factor);
In function vect_analyze_loop_2, the current place of
on 2022/6/8 11:28, 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 instead
> of
on 2022/6/6 18:01, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi,
>>
>> r10-3912 updated the format of VECTOR_MODES_WITH_PREFIX by
>> adding one more parameter ORDER, the related document is out
>> of date. So update the document for ORDER.
>>
>> Is it ok for trunk?
>>
>> BR,
>> Kewen
>>
Hi Will,
The whole series looks good to me, thanks! IMHO one place can be
further refactored, not sure if it's worth to updating together in
this series, it's ...
on 2022/6/7 06:05, will schmidt wrote:
> [PATCH,RS6000 2/5) Rework the RS6000_BTM defines.
>
> The RS6000_BTM_ definitions are
Hi,
Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595209.html
BR,
Kewen
on 2022/5/18 22:07, Kewen.Lin via Gcc-patches wrote:
> 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 emi
Hi,
Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595209.html
BR,
Kewen
on 2022/5/18 22:07, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As PR104482 shown, it's one regression about the handlings when
> the argument number is more than the one of built-in function
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
> unresolved overloaded builtin function well. With
Hi Haochen,
on 2022/6/6 10:21, HAO CHEN GUI wrote:
> Hi,
> This patch replaces shift and ior insns with one rotate and mask
> insn for the split patterns which are for DI byte swap on Power6 and
> before. The test cases shows the optimization.
Nit: I noticed two splitting which are updated in
Hi,
r10-3912 updated the format of VECTOR_MODES_WITH_PREFIX by
adding one more parameter ORDER, the related document is out
of date. So update the document for ORDER.
Is it ok for trunk?
BR,
Kewen
-
gcc/ChangeLog:
* machmode.def (VECTOR_MODES_WITH_PREFIX): Update document for
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 that the target
option node is also necessary to be rebuilt. Without updating
target option node early, it can
Hi Haochen,
on 2022/5/31 09:52, HAO CHEN GUI wrote:
> Hi,
>This patch adds V1TI mode into a new mode iterator used in vector
> comparison shift and rotation expands. Without the patch, the comparisons
> between two vector __int128 are converted to scalar comparisons and
> code is suboptimal.
Hi Haochen,
on 2022/5/26 15:35, HAO CHEN GUI wrote:
> Hi,
> This patch fixes the ICE reported in PR100736. It removes the condition
> check of finite math only flag not setting in "*_cc" pattern.
> With or without this flag, we still can use "cror" to check if either
> two bits of CC is set or
Hi Haochen,
on 2022/5/18 16:52, 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
on 2022/5/26 14:12, Kewen.Lin via Gcc-patches wrote:
> Hi Will,
>
> on 2022/5/26 04:25, will schmidt via Gcc-patches wrote:
>> [PATCH, rs6000] Clean up the option_mask defines
>>
>> Hi,
>>
>> We have an assortment of MASK and OPTION_MASK #defines thro
Hi Will,
on 2022/5/26 04:25, will schmidt via Gcc-patches wrote:
> [PATCH, rs6000] Clean up the option_mask defines
>
> Hi,
>
> We have an assortment of MASK and OPTION_MASK #defines throughout
> the rs6000 code, MASK_ALTIVEC and OPTION_MASK_ALTIVEC as an example.
>
> We currently #define
Hi Haochen,
on 2022/5/26 13:30, HAO CHEN GUI wrote:
> Kewen,
> Thanks so much for your advice. Just one question about effective-target.
>
> For the test cases, it needs both power10_ok and int128 support. I saw some
> existing test cases have these two checks as well. But I wonder if
Hi Haochen,
on 2022/5/24 16:45, HAO CHEN GUI wrote:
> Hi,
>This patch adds V1TI mode into a new mode iterator used in vector
> comparison and rotation expands. Without the patch, the comparisons
> between two vector __int128 are converted to scalar comparisons. The
> code is suboptimal. The
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
401 - 500 of 1022 matches
Mail list logo
