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")
>> -(i
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
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
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
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
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. I
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")));
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_INS
on 2021/6/30 下午4:53, Hongtao Liu wrote:
> On Mon, Jun 28, 2021 at 3:27 PM Kewen.Lin wrote:
>>
>> 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 wr
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
Hi Richard,
on 2021/6/30 下午11:42, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> 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 w
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:
>>&
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.
>&g
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 i
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 le
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
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 q
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 failur
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 ar
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
>> mad
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
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:
>>&
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
>
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 o
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:
>>>>
>>>> H
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
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,
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,
>>>>
>>&
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.
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
Hi,
By addressing Alexander's comments, against v1 this
patch v2 mainly:
- Rename no_real_insns_p to no_real_nondebug_insns_p;
- Introduce enum rgn_bb_deps_free_action for three
kinds of actions to free deps;
- Change function free_deps_for_bb_no_real_insns_p to
resolve_forw_deps wh
Hi Haochen,
on 2023/3/28 15:45, 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 element
> of the input vector that would fall in the least significant portion of the
> result el
Hi Segher,
Thanks for the review!
on 2023/4/3 19:44, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Feb 17, 2023 at 05:55:04PM +0800, Kewen.Lin wrote:
>> As PR108807 exposes, the current handling in function
>> rs6000_expand_vector_set_var_p9 doesn't take care of big
>
Hi,
The test case gcc.target/powerpc/pr83677.c was written for
LE environment, this patch is to make it work on BE as well.
Tested on BE and LE well, I'm going to push this soon if no
objections.
BR,
Kewen
-
PR testsuite/108815
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/
Hi Alexandre,
on 2023/4/6 12:43, Alexandre Oliva wrote:
> Hello, Kewen,
>
> Thanks for the feedback.
>
> On Mar 27, 2023, "Kewen.Lin" wrote:
>
>> on 2023/3/25 16:37, Alexandre Oliva via Gcc-patches wrote:
>>>
>>> When long double is 64-bit
Hi Alexandre,
on 2023/4/6 13:20, Alexandre Oliva wrote:
> Hello, Kewen,
>
> On Mar 27, 2023, "Kewen.Lin" wrote:
>
>> on 2023/3/25 16:35, Alexandre Oliva wrote:
>
>>> The first loop in main gets stores "vectorized" on powerpc into
>>
Hi Haochen,
on 2023/4/6 13:35, 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 element
> of the input vector that would fall in the least significant portion of the
> result ele
Hi Alexandre,
on 2023/4/6 14:19, Alexandre Oliva wrote:
>
> Skip ppc-fortran.exp if a trivial fortran program cannot be compiled.
>
IIUC, without this patch and under the configuration disabling fortran,
all the cases in this sub-testsuite would fail? Thanks for fixing!
> Regstrapped on x86_6
Hi Alexandre,
on 2023/4/7 09:48, Alexandre Oliva wrote:
> On Apr 6, 2023, "Kewen.Lin" wrote:
>
>> The reason why personally I preferred to fix it with xfail is that:
>
> Got it. I'm convinced, and I agree.
>
> I tried an xfail in the initial dg-do, bu
1501 - 1600 of 1615 matches
Mail list logo
