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 appl
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 is
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 in
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
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 the
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-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 and
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
>> err
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 a
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 can
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 cir
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,
As Segher and Mike pointed out, the define_insn_and_split should avoid
to use empty split condition if the condition for define_insn isn't empty,
otherwise it can sometimes leads to unexpected consequence.
This patch is to fix some places like this.
Bootstrapped/regtested on powerpc64le-linu
Hi Segher,
Thanks for the review.
on 2021/3/19 下午8:36, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Mar 19, 2021 at 10:46:54AM +0800, Kewen.Lin wrote:
>> As Segher and Mike pointed out, the define_insn_and_split should avoid
>> to use empty split condition if the condition for define_insn isn't e
Hi Segher,
on 2021/3/20 上午5:58, Segher Boessenkool wrote:
> On Fri, Mar 19, 2021 at 11:50:41PM +0800, Kewen.Lin wrote:
>>> I am curious if the splitters ever triggered where they should not have?
>>
>> Do you have any suggestion to catch this? I thought the regression
>> testing probably can show
Hi,
I happened to find this possible use of uninitialized inside_cost during
checking the cost for reduction. Before r11-6587, all the if/else if/else
arms will assign values to inside_cost, so it was fine. But from r11-6587
the else path won't assign any more, it leads the inside_cost possibly
Hi,
Recently if we build gcc on Power with the assembler which doesn't
have Power10 support, the build will fail when building libgcc with
one error message like:
Error: invalid switch -mpower10
Error: unrecognized option -mpower10
make[2]: *** [...gcc/gcc-base/libgcc/shared-object.mk:14: float12
Hi Richi and Martin,
>>
>> Thanks Richi! One draft (not ready for review) is attached for the further
>> discussion. It follows the idea of RAII-style cleanup. I noticed that
>> Martin suggested stepping forward to make tree_predictive_commoning_loop
>> and its callees into one class (Thanks Ma
Hi Segher,
Thanks for the prompt review!
on 2021/6/23 上午2:56, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jun 21, 2021 at 05:27:06PM +0800, Kewen.Lin wrote:
>> Recently if we build gcc on Power with the assembler which doesn't
>> have Power10 support, the build will fail when building libgcc wit
Hi Martin,
on 2021/6/23 上午12:14, Martin Sebor wrote:
> On 6/21/21 8:35 PM, Kewen.Lin wrote:
>> Hi Richi and Martin,
>>
Thanks Richi! One draft (not ready for review) is attached for the further
discussion. It follows the idea of RAII-style cleanup. I noticed that
Martin sugg
on 2021/6/23 下午3:22, Richard Biener wrote:
> On Tue, Jun 22, 2021 at 4:35 AM Kewen.Lin wrote:
>>
>> Hi Richi and Martin,
>>
Thanks Richi! One draft (not ready for review) is attached for the further
discussion. It follows the idea of RAII-style cleanup. I noticed that
Martin
on 2021/6/24 上午12:58, Segher Boessenkool wrote:
> On Wed, Jun 23, 2021 at 12:17:07PM +0800, Kewen.Lin wrote:
+#ifdef FLOAT128_HW_INSNS_ISA3_1
TFtype __floattikf (TItype_ppc)
__attribute__ ((__ifunc__ ("__floattikf_resolve")));
>>>
>>> I wonder if we now need TItype_ppc at all any
Hi!
on 2021/6/9 下午1:18, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> PR100328 has some details about this issue, I am trying to
> brief it here. In the hottest function LBM_performStreamCollideTRT
> of SPEC2017 bmk 519.lbm_r, there are many FMA style expressions
> (27 FMA, 19
Hi!
I'd like to gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572555.html
BR,
Kewen
on 2021/6/11 下午9:16, Kewen.Lin via Gcc-patches wrote:
> Hi Segher,
>
> Thanks for the review!
>
> on 2021/6/10 上午4:17, Segher Boessenkool wrote:
>> Hi!
>
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571258.html
BR,
Kewen
on 2021/6/9 上午10:26, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> Gentle ping this:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571258.html
>
> BR,
> Kewen
&
on 2021/6/28 下午3:20, Hongtao Liu wrote:
> On Mon, Jun 28, 2021 at 3:12 PM Hongtao Liu wrote:
>>
>> On Mon, Jun 28, 2021 at 2:50 PM Kewen.Lin wrote:
>>>
>>> Hi!
>>>
>>> on 2021/6/9 下午1:18, Kewen.Lin via Gcc-patches wrote:
>>>> Hi,
&g
on 2021/6/25 上午3:36, Segher Boessenkool wrote:
> On Thu, Jun 24, 2021 at 05:32:20PM +0800, Kewen.Lin wrote:
>> on 2021/6/24 上午12:58, Segher Boessenkool wrote:
>>> On Wed, Jun 23, 2021 at 12:17:07PM +0800, Kewen.Lin wrote:
>> +#ifdef FLOAT128_HW_INSNS_ISA3_1
>> TFtype __floattikf (TItype_pp
ote:
>>>>>
>>>>> Hi!
>>>>>
>>>>> on 2021/6/9 下午1:18, Kewen.Lin via Gcc-patches wrote:
>>>>>> Hi,
>>>>>>
>>>>>> PR100328 has some details about this issue, I am trying to
>>>>
Hi Vladimir,
on 2021/6/30 下午11:24, Vladimir Makarov wrote:
>
> On 2021-06-28 2:26 a.m., Kewen.Lin wrote:
>> Hi!
>>
>> on 2021/6/9 下午1:18, Kewen.Lin via Gcc-patches wrote:
>>> Hi,
>>>
>>> PR100328 has some details about this issue, I am tr
rote:
>>>>>
>>>>> Hi!
>>>>>
>>>>> on 2021/6/9 下午1:18, Kewen.Lin via Gcc-patches wrote:
>>>>>> Hi,
>>>>>>
>>>>>> PR100328 has some details about this issue, I am trying to
>>>>>>
Hi,
With Hongtao's help (thanks), we got the SPEC2017 performance
evaluation result on x86_64 (see [1]), this new parameter
ira-consider-dup-in-all-alts has negative effects on i386.
Since we observed it can benefit ports aarch64 and rs6000, the
param is set as 1 by default, this patch is to disab
Hi Segher,
on 2022/11/18 23:10, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Nov 17, 2022 at 02:59:00PM +0800, Kewen.Lin wrote:
>> on 2022/11/17 02:44, Segher Boessenkool wrote:
>>> On Wed, Nov 16, 2022 at 02:48:25PM +0800, Kewen.Lin wrote:
* config/rs6000/rs6000.cc (rs6000_emit_vector_com
Hi Richard,
Many thanks for your review comments!
>>> 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 wo
Hi Haochen,
Thanks for the explanation.
on 2022/11/21 14:18, HAO CHEN GUI wrote:
> Hi Segher,
>
> 在 2022/11/18 20:18, Segher Boessenkool 写道:
>> I don't think we should pretend we have any conditional jumps the
>> machine does not actually have, in cbranchcc4. When would this ever be
>> useful?
Hi Haochen,
on 2022/11/22 13:12, HAO CHEN GUI wrote:
> Hi Kewen,
>
> 在 2022/11/22 11:11, Kewen.Lin 写道:
>> Maybe we can adjust prepare_cmp_insn to fail if the constructed cbranchcc4
>> pattern doesn't satisfy the predicate of operand 0 rather than to assert.
>> It's something like:
>>
>> if (!insn
Hi Richard,
on 2022/11/23 00:08, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>
>> Many thanks for your review comments!
>>
>>>>> on 2022/8/24 16:17, Kewen.Lin via Gcc-patches wrote:
>>>>>> Hi,
Hi Haochen,
Sorry for the late review.
on 2022/10/11 15:38, HAO CHEN GUI wrote:
> Hi,
> This patch modifies the help function which generates permute index for
> vector byte reversion and generates permute index directly for little endian
> targets. It saves one "xxlnor" instructions on P8 litt
Hi Jeff,
Sorry for the late reply.
on 2022/10/26 19:40, Jiufu Guo wrote:
> Hi,
>
> PR106708 constaint some constants which can be support by li/lis + oris/xoris.
typo?
for "li/lis + oris/xoris", I interpreted it into four combinations:
li + oris, lis + oris, li + xoris,
Hi Haochen,
Sorry for the late reply.
on 2022/11/7 14:45, HAO CHEN GUI wrote:
> Hi,
> For scalar extract/insert instructions, exponent field can be stored in a
> 32-bit register. So this patch changes the mode of exponent field from DI to
> SI. So these instructions can be generated in a 32-bit
Hi Jeff,
Sorry for the late review.
on 2022/9/15 16:30, Jiufu Guo wrote:
> Hi,
>
> For a complicate 64bit constant, blow is one instruction-sequence to
> build:
> lis 9,0x800a
> ori 9,9,0xabcd
> sldi 9,9,32
> oris 9,9,0xc167
> ori 9,9,0xfa16
>
> while we can also u
Hi Segher,
on 2022/11/25 23:46, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Nov 25, 2022 at 09:21:21PM +0800, Jiufu Guo wrote:
>> "Kewen.Lin" writes:
>>> on 2022/9/15 16:30, Jiufu Guo wrote:
For a complicate 64bit constant, blow is one instruction-sequence to
build:
lis 9,0x800
Hi Richard,
on 2022/11/24 17:24, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi,
>>
>> As the test case in PR107412 shows, we can fold IFN .LEN_{LOAD,
>> STORE} into normal vector load/store if the given length is known
>> to be equal to the length of the whole vector. It would help to
>>
Add more experts in CC.
on 2022/11/23 10:54, HAO CHEN GUI wrote:
> Hi,
> I want to enable "have_cbranchcc4" on rs6000. But not all combinations of
> comparison codes and sub CC modes are benefited to generate cbranchcc4 insns
> on rs6000. There is an predicate for operand0 of cbranchcc4 to bypas
Hi,
As PR104024 shows, the option -mpower10-fusion isn't guarded by
-mcpu=power10, it causes compiler to fuse for some patterns
even without power10 support and then causes ICE unexpectedly,
this patch is to simply unmask it without power10 support, not
emit any warnings as this option is undocume
Hi,
Function optimize_function_for_size_p returns OPTIMIZE_SIZE_NO
if fun->decl is not null but no cgraph node is available for it.
As PR105818 shows, this could cause unexpected consequence. For
the case in PR105818, when parsing bar decl in function foo, the
cfun is the function structure for f
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603350.html
BR,
Kewen
on 2022/10/12 16:12, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> PR106680 shows that -m32 -mpowerpc64 is different from
> -mpowerpc64 -m32, this is determined by the way how we
>
Hi Jeff,
on 2022/12/1 09:36, Jiufu Guo wrote:
> Hi,
>
> Function rs6000_emit_set_const/rs6000_emit_set_long_const are only invoked
> from
> two "define_split"s where the target operand is limited to gpc_reg_operand or
> int_reg_operand, then the operand must be REG_P.
> And in rs6000_emit_set_co
Hi Jeff,
on 2022/12/1 09:36, Jiufu Guo wrote:
> Hi,
>
> This patch just uses sext_hwi to replace the expression like:
> ((value & 0xf..f) ^ 0x80..0) - 0x80..0 for rs6000.cc and rs6000.md.
>
> Bootstrap & regtest pass on ppc64{,le}.
> Is this ok for trunk?
You didn't say it clearly but I guesse
on 2022/12/1 13:17, Kewen.Lin via Gcc-patches wrote:
> Hi Jeff,
>
> on 2022/12/1 09:36, Jiufu Guo wrote:
>> Hi,
>>
>> This patch just uses sext_hwi to replace the expression like:
>> ((value & 0xf..f) ^ 0x80..0) - 0x80..0 for rs6000.cc and rs6000.md.
>&g
on 2022/12/1 13:35, Jiufu Guo wrote:
> Hi Kewen,
>
> Thanks for your quick and insight review!
>
> 在 12/1/22 1:17 PM, Kewen.Lin 写道:
>> Hi Jeff,
>>
>> on 2022/12/1 09:36, Jiufu Guo wrote:
>>> Hi,
>>>
>>> This patch just uses sext_hwi to replace the expression like:
>>> ((value & 0xf..f) ^ 0x80..0)
on 2022/12/1 20:16, guojiufu wrote:
> On 2022-12-01 15:10, Jiufu Guo via Gcc-patches wrote:
>> Hi Kewen,
>>
>> 在 12/1/22 2:11 PM, Kewen.Lin 写道:
>>> on 2022/12/1 13:35, Jiufu Guo wrote:
Hi Kewen,
Thanks for your quick and insight review!
在 12/1/22 1:17 PM, Kewen.Lin 写道:
Hi Mike,
Thanks for fixing this!
on 2022/11/2 10:40, Michael Meissner wrote:
> This function reworks how the complex multiply and divide built-in functions
> are
> done. Previously we created built-in declarations for doing long double
> complex
> multiply and divide when long double is IEEE 1
Hi Mike,
Thanks for fixing this, some comments are inlined below.
on 2022/11/2 10:42, Michael Meissner wrote:
> This patch fixes the issue that GCC cannot build when the default long double
> is IEEE 128-bit. It fails in building libgcc, specifically when it is trying
> to buld the __mulkc3 func
Hi,
In the recent discussion on how to make some built-in type only valid for
some target features efficiently[1], Andrew mentioned this patch which he
made previously (Thanks!). I confirmed it can help rs6000 related issue,
and noticed PR99657 is still opened, so I think we still want this to
be
Hi Haochen,
on 2022/12/6 13:44, HAO CHEN GUI wrote:
> Hi,
> This patch enables "have_cbranchcc4" on rs6000 by defining
> a "cbranchcc4" expander. "have_cbrnachcc4" is a flag in ifcvt.cc
> to indicate if branch by CC bits is invalid or not. With this
> flag enabled, some branches can be optimized
on 2022/12/7 13:24, HAO CHEN GUI wrote:
> Hi Kewen,
> Thanks so much for your review comments. I will fix them.
>
> 在 2022/12/7 11:06, Kewen.Lin 写道:
>> Does this issue which relies on the fix for generic part make bootstrapping
>> fail?
>> If no, how many failures it can cause? I'm thinking if
Hi Mike,
on 2022/12/7 14:44, Michael Meissner wrote:
> On Tue, Dec 06, 2022 at 05:36:54PM +0800, Kewen.Lin wrote:
>> Hi Mike,
>>
>> Thanks for fixing this!
>>
>> Could you help to elaborate why we need to disable it during libgcc building?
>
> When you are building libgcc, you are building the __
Hi Richard,
on 2022/12/7 17:16, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi,
>>
>> In the recent discussion on how to make some built-in type only valid for
>> some target features efficiently[1], Andrew mentioned this patch which he
>> made previously (Thanks!). I confirmed it can help
on 2022/12/7 20:55, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>
>> on 2022/12/7 17:16, Richard Sandiford wrote:
>>> "Kewen.Lin" writes:
Hi,
In the recent discussion on how to make some built-in type only valid for
some target features efficiently[1], Andre
Hi Haochen,
Thanks for the update, some comments are inlined as below.
on 2022/12/2 15:03, HAO CHEN GUI wrote:
> Hi,
> For scalar extract/insert instructions, exponent field can be stored in a
> 32-bit register. So this patch changes the mode of exponent field from DI to
> SI so that these inst
Hi Haochen,
on 2022/12/8 11:08, HAO CHEN GUI wrote:
> Hi,
> This patch enables "have_cbranchcc4" on rs6000 by defining
> a "cbranchcc4" expander. "have_cbrnachcc4" is a flag in ifcvt.cc
> to indicate if branch by CC bits is invalid or not. With this
> flag enabled, some branches can be optimized
on 2022/12/8 15:43, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> on 2022/12/7 20:55, Richard Sandiford wrote:
>>> "Kewen.Lin" writes:
Hi Richard,
on 2022/12/7 17:16, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi,
>>
>> In the recent discussion on how to
Hi,
This patch is to fix one wrong assertion which is too aggressive.
Vectorizer can do vec_construct costing for the vector type which
only has one unit. For the failed case, the passed-in vector type
is "vector(1) int", though it doesn't end up with any construction
eventually. We have to han
Hi,
As PR103627 shows, there is an unexpected case where !TARGET_VSX
and TARGET_MMA co-exist. As ISA3.1 claims, SIMD is a requirement
for MMA. By looking into the ICE, I noticed that the current
MMA implementation depends on vector pairs load/store, but since
we don't have a separated option to
Hi,
There is one hunk checking for functions with target attribute/pragma
have the same altivec abi as the one of main_target_opt, it can update
both VSX and ALTIVEC flags. Meanwhile, we have some codes to check or
warn for some isa flags related to VSX and ALTIVEC, that sit where the
mentioned h
Hi,
When TARGET_AVOID_XFORM is set, we turn off VSX. But at least from
ISA3.0 (Power9), we support DQ form vector load/store. This patch
is to make it not clear VSX when P9 VECTOR supported, it also checks
some flags which P9 VECTOR relies on, otherwise those flags could
disable P9 VECTOR later.
Hi,
Option -mpower10 was made as "WarnRemoved" since commit r11-2318,
so -mno-power10 doesn't take effect any more. This patch is to
remove one line useless code which still respects it.
Bootstrapped and regtested on powerpc64le-linux-gnu P9 and
powerpc64-linux-gnu P8.
Is it ok for trunk?
BR,
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 unexpected, we should use the command line options
from target_option_default_node as def
on 2022/1/11 上午8:26, David Edelsohn wrote:
> On Wed, Dec 29, 2021 at 4:37 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> Option -mpower10 was made as "WarnRemoved" since commit r11-2318,
>> so -mno-power10 doesn't take effect any more. This patch is to
>> remove one line useless code which still respects it
Hi,
This patch is to fix register constraint v with
rs6000_constraints[RS6000_CONSTRAINT_v] instead of ALTIVEC_REGS,
just like some other existing register constraints with
RS6000_CONSTRAINT_*.
I happened to see this and hope it's not intentional and just
got neglected.
Bootstrapped and regtest
Hi,
This patch is to clean up some codes with GET_MODE_UNIT_SIZE or
GET_MODE_NUNITS, which can use known constant instead.
Bootstrapped and regtested on powerpc64le-linux-gnu P9 and
powerpc64-linux-gnu P8.
Is it ok for trunk?
BR,
Kewen
-
gcc/ChangeLog:
* config/rs6000/altivec.md (a
Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587309.html
on 2021/12/23 上午10:06, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> This patch is to fix one wrong assertion which is too aggressive.
> Vectorizer can do vec_construct costing for the vector type whic
Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587310.html
on 2021/12/23 上午10:09, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As PR103627 shows, there is an unexpected case where !TARGET_VSX
> and TARGET_MMA co-exist. As ISA3.1 claims, SIMD is a requirement
&g
Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587311.html
on 2021/12/23 上午10:12, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> There is one hunk checking for functions with target attribute/pragma
> have the same altivec abi as the one of main_target_opt, i
Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587449.html
on 2021/12/29 下午5:36, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> When TARGET_AVOID_XFORM is set, we turn off VSX. But at least from
> ISA3.0 (Power9), we support DQ form vector load/store. This patch
Hi David,
on 2022/1/13 上午11:07, David Edelsohn wrote:
> On Wed, Jan 12, 2022 at 8:56 PM Kewen.Lin wrote:
>>
>> Hi,
>>
>> This patch is to fix register constraint v with
>> rs6000_constraints[RS6000_CONSTRAINT_v] instead of ALTIVEC_REGS,
>> just like some other existing register constraints with
>
on 2022/1/13 上午11:44, David Edelsohn wrote:
> On Wed, Jan 12, 2022 at 10:38 PM Kewen.Lin wrote:
>>
>> Hi David,
>>
>> on 2022/1/13 上午11:07, David Edelsohn wrote:
>>> On Wed, Jan 12, 2022 at 8:56 PM Kewen.Lin wrote:
Hi,
This patch is to fix register constraint v with
rs600
on 2022/1/13 上午11:56, Kewen.Lin via Gcc-patches wrote:
> on 2022/1/13 上午11:44, David Edelsohn wrote:
>> On Wed, Jan 12, 2022 at 10:38 PM Kewen.Lin wrote:
>>>
>>> Hi David,
>>>
>>> on 2022/1/13 上午11:07, David Edelsohn wrote:
>>>> On Wed,
Hi David,
on 2022/1/13 上午11:12, David Edelsohn wrote:
> On Wed, Jan 12, 2022 at 8:56 PM Kewen.Lin wrote:
>>
>> Hi,
>>
>> This patch is to clean up some codes with GET_MODE_UNIT_SIZE or
>> GET_MODE_NUNITS, which can use known constant instead.
>
> I'll let Segher decide, but often the additional
on 2022/1/13 下午11:15, David Edelsohn wrote:
> On Thu, Jan 13, 2022 at 7:40 AM Kewen.Lin wrote:
>>
>> Hi David,
>>
>> on 2022/1/13 上午11:12, David Edelsohn wrote:
>>> On Wed, Jan 12, 2022 at 8:56 PM Kewen.Lin wrote:
Hi,
This patch is to clean up some codes with GET_MODE_UNIT_SIZ
Hi,
As described in PR104015, the function partial_vectors_supported_p
mainly checks optabs for partial vectors support query, but we
still have one parameter param_vect_partial_vector_usage to control
the capability.
Power9 introduces vector with length instructions (for
len_load/len_store) but
on 2022/1/14 下午9:53, David Edelsohn wrote:
> On Fri, Jan 14, 2022 at 5:42 AM Kewen.Lin wrote:
>>
>> on 2022/1/13 下午11:15, David Edelsohn wrote:
>>> On Thu, Jan 13, 2022 at 7:40 AM Kewen.Lin wrote:
Hi David,
on 2022/1/13 上午11:12, David Edelsohn wrote:
> On Wed, Jan 12, 2022
Hi,
As discussed in PR104015, the test case slp-perm-9.c can be
fragile when vectorizer tries to use different vectorisation
strategies.
As Richard suggested, this patch tries to make the check not
sensitive on the re-trying times by removing the times checking.
To still retain the test coverage
on 2022/1/18 上午11:06, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As discussed in PR104015, the test case slp-perm-9.c can be
> fragile when vectorizer tries to use different vectorisation
> strategies.
>
> As Richard suggested, this patch tries to make the check not
> se
Hi Peter,
on 2023/3/18 10:30, Peter Bergner wrote:
> On 3/17/23 7:17 PM, Peter Bergner wrote:
>> On 3/17/23 5:35 PM, Peter Bergner wrote:
>>> When we expand the __builtin_vec_xst_trunc built-in, we use the wrong mode
>>> for the MEM operand which causes an unrecognizable insn ICE. The solution
>>
Hi,
As PR108273 shows, when there is one block which only has
NOTE_P and LABEL_P insns at non-debug mode while has some
extra DEBUG_INSN_P insns at debug mode, after scheduling
it, the DFA states would be different between debug mode
and non-debug mode. Since at non-debug mode, the block
meets no
Hi,
The failures on the original failed case builtin-bitops-1.c
and the associated test case pr108699.c here show that the
current support of parity vector mode is wrong on Power.
The hardware insns vprtyb[wdq] which operate on the least
significant bit of each byte per element, they doesn't match
Hi,
As PR109082 shows, some uses of vec_sld in emmintrin.h don't
strictly guarantee the given shift count is in the range
0-15 (inclusive). This patch is to make the argument
range constraint honored for those uses.
Bootstrapped and regtested on powerpc64-linux-gnu P8 and
powerpc64le-linux-gnu P
Hi,
As PR109167 shows, it's unexpected to have two different
implementation ways for _mm_slli_si128 and _mm_bslli_si128,
as gcc/config/i386/emmintrin.h they should be the same. So
this patch is to fix it accordingly.
Bootstrapped and regtested on powerpc64-linux-gnu P8 and
powerpc64le-linux-gnu
Hi,
One of my workmates found there is a warning like:
libgcc/config/rs6000/morestack.S:402: Warning: ignoring
incorrect section type for .init_array.0
when compiling libgcc/config/rs6000/morestack.S.
Since commit r13-6545 touched that file recently, which was
suspected to be responsi
Hi,
I'd like to gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612213.html
It's to fix one regression, I think it's stage 4 content.
BR,
Kewen
on 2023/2/17 17:55, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As PR108807 exposes, the curr
Hi Alexander,
Thanks a lot for your comments and suggestions!
on 2023/3/20 16:03, Alexander Monakov wrote:
>
> On Mon, 20 Mar 2023, Kewen.Lin wrote:
>
>> Hi,
>
> Hi. Thank you for the thorough analysis. Since I analyzed
> PR108519, I'd like to offer my comments.
>
>> As PR108273 shows, when t
Hi Mike,
Thanks for fixing this, some minor comments are inlined below.
on 2023/3/22 07:53, Michael Meissner wrote:
> The issue with the bug is the power10 load GPR + cmpi -1/0/1 fusion
> optimization generates illegal assembler code.
>
> Ultimately the code was dying because the fusion load + c
Hi Mike,
on 2023/3/25 07:06, Michael Meissner wrote:
> I posted a version of patch on March 21st. This patch makes some code changes
> suggested in the genfusion.pl code. The only change is in genfusion.pl. The
> fusion.md that it makes is the same.
>
> The issue with the bug is the power10 lo
Hi Alexandre,
on 2023/3/25 16:35, Alexandre Oliva wrote:
>
> The first loop in main gets stores "vectorized" on powerpc into
> full-word stores, even without any vector instruction support, so the
> test's expectation of no loop vectorization is not met.
>
I think this test issue has been gone
Hi Alexandre,
Thanks for fixing this.
on 2023/3/25 16:37, Alexandre Oliva via Gcc-patches wrote:
>
> When long double is 64-bit wide, as on vxworks, the rs6000 backend
> defines neither the __ibm128 type nor the __SIZEOF_IBM128__ macro, but
> pr99708.c expected both to be always defined. Adjust
Hi Haochen,
Thanks for fixing this.
on 2023/3/27 14:16, HAO CHEN GUI wrote:
> Hi,
> This patch removes byte reverse operation before vector integer sign
> extension on Big Endian. These built-ins require to sign extend the rightmost
> element. So both BE and LE should do the same operation and
Hi Alexandre and Haochen,
on 2023/3/25 16:42, Alexandre Oliva via Gcc-patches wrote:
>
> Ping https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590958.html
>
> From: Haochen Gui
>
> This patch corrects the match pattern in pr56605.c. The former pattern
> is wrong and test case fails with
Hi,
As PR109069 shows, commit r12-6537-g080a06fcb076b3 which
introduces define_insn_and_split sldoi_to_mov adopts
easy_vector_constant for const vector of interest, but it's
wrong since predicate easy_vector_constant doesn't guarantee
each byte in the const vector is the same. One counter
example
Hi Haochen,
on 2023/3/27 17:46, HAO CHEN GUI wrote:
> Kewen,
> The case still fails with trunk.
>
OK, thanks for checking, the proposed patch can catch the expected pattern
accurately (excluding noises), so okay for trunk and branches, thanks!
BR,
Kewen
> FAIL: gcc.target/powerpc/pr56605.c s
901 - 1000 of 1024 matches
Mail list logo
