Hi Carl,
on 2023/5/19 05:12, Carl Love via Gcc-patches wrote:
> GCC maintainers:
>
> version 2. Fixed an issue with the test case. The dg-options line was
> missing.
>
> The following patch adds an overloaded builtin. There are two possible
> arguments for the builtin. The builtin definition
Hi Haochen,
on 2023/5/4 16:56, HAO CHEN GUI wrote:
> Hi,
> This patch adds a new insn for vector splat with small V2DI constants on P8.
> If the value of constant is in RANGE (-16, 15) and not 0 or -1, it can be
> loaded
> with vspltisw and vupkhsw on P8. It should be efficient than loading vec
Hi Carl,
on 2023/5/11 02:06, Carl Love via Gcc-patches wrote:
> GCC maintainers:
>
> The following patch fixes errors in the arguments in the
> __builtin_altivec_tr_stxvrhx, __builtin_altivec_tr_stxvrwx builtin
> definitions. Note, these builtins are used by the overloaded
> __builtin_vec_xst_tr
Hi Haochen,
on 2023/2/8 13:08, HAO CHEN GUI wrote:
> Hi,
> The logical operations for TImode is split after reload pass right now. Some
> potential optimizations miss as the split is too late. This patch removes
> TImode from "AND", "IOR", "XOR" and "NOT" expander so that these logical
> operati
Hi Richi,
Thanks for the review!
on 2023/5/22 21:44, Richard Biener wrote:
> On Wed, May 17, 2023 at 8:15 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> Following Richi's suggestion in [1], I'm working on deferring
>> cost evaluation next to the transformation, this patch is
>> to enhance function vect_tra
on 2023/5/23 03:50, Carl Love wrote:
> On Mon, 2023-05-22 at 17:04 +0800, Kewen.Lin wrote:
>> Hi Carl,
>>
>> on 2023/5/11 02:06, Carl Love via Gcc-patches wrote:
>>> GCC maintainers:
>>>
>>> The following patch fixes errors in the arguments in the
>>> __builtin_altivec_tr_stxvrhx, __builtin_a
on 2023/5/23 01:31, Carl Love wrote:
> On Mon, 2023-05-22 at 14:36 +0800, Kewen.Lin wrote:
>> Hi Carl,
>>
>> on 2023/5/19 05:12, Carl Love via Gcc-patches wrote:
>>> GCC maintainers:
>>>
>>> version 2. Fixed an issue with the test case. The dg-options line
>>> was
>>> missing.
>>>
>>> The followi
on 2023/5/23 14:19, Richard Biener wrote:
> On Tue, May 23, 2023 at 5:01 AM Kewen.Lin wrote:
>>
>> Hi Richi,
>>
>> Thanks for the review!
>>
>> on 2023/5/22 21:44, Richard Biener wrote:
>>> On Wed, May 17, 2023 at 8:15 AM Kewen.Lin wrote:
Hi,
Following Richi's suggestion in [1
on 2023/5/24 06:30, Peter Bergner wrote:
> On 5/23/23 12:24 AM, Kewen.Lin wrote:
>> on 2023/5/23 01:31, Carl Love wrote:
>>> The builtins were requested for use in GLibC. As of version 2.31 they
>>> were added as inline asm. They requested a builtin so the asm could be
>>> removed.
>>
>> So IMHO
on 2023/5/24 13:42, Alexandre Oliva via Gcc-patches wrote:
>
> The bogus warning is present on 32-bit ppc-vx7r2 too, so drop the 64
> from the powerpc xfail triplet.
>
> Bootstrapped on x86_64-linux-gnu. Also tested on ppc- and x86-vx7r2
> with gcc-12.
It xfail-ed on my local BE -m32 testing bu
on 2023/5/24 23:20, Carl Love wrote:
> On Wed, 2023-05-24 at 13:32 +0800, Kewen.Lin wrote:
>> on 2023/5/24 06:30, Peter Bergner wrote:
>>> On 5/23/23 12:24 AM, Kewen.Lin wrote:
on 2023/5/23 01:31, Carl Love wrote:
> The builtins were requested for use in GLibC. As of version
> 2.31 th
Hi Alexandre,
on 2023/5/24 13:51, Alexandre Oliva wrote:
>
> Codegen changes caused add instruction count mismatches on
> ppc-*-linux-gnu and other 32-bit ppc targets. At some point the
> expected counts were adjusted for lp64, but ilp32 differences
> remained, and published test results confirm
Hi Segher,
on 2021/1/22 上午8:30, Segher Boessenkool wrote:
> Hi Ke Wen,
>
> On Fri, Jan 15, 2021 at 04:06:17PM +0800, Kewen.Lin wrote:
>> on 2021/1/15 上午8:22, Segher Boessenkool wrote:
>>> On Wed, Dec 16, 2020 at 04:49:49PM +0800, Kewen.Lin wrote:
... op regX // this regX could find wrong
Hi Segher/Richard B./Richard S.,
Many thanks for your all helps and comments on this!
on 2021/1/25 下午3:56, Richard Biener wrote:
> On Fri, 22 Jan 2021, Segher Boessenkool wrote:
>
>> On Fri, Jan 22, 2021 at 02:47:06PM +0100, Richard Biener wrote:
>>> On Thu, 21 Jan 2021, Segher Boessenkool wrote
on 2021/1/26 上午1:59, Richard Sandiford via Gcc-patches wrote:
> Richard Biener writes:
>> On Fri, 22 Jan 2021, Segher Boessenkool wrote:
>>
>>> On Fri, Jan 22, 2021 at 02:47:06PM +0100, Richard Biener wrote:
On Thu, 21 Jan 2021, Segher Boessenkool wrote:
> What is holding up this patch st
on 2021/1/26 上午4:37, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jan 25, 2021 at 05:59:23PM +, Richard Sandiford wrote:
>> Richard Biener writes:
>>> On Fri, 22 Jan 2021, Segher Boessenkool wrote:
But what could have been done differently that would have helped? Of
course Ke Wen co
on 2021/1/26 下午6:53, Richard Biener wrote:
> On Tue, 26 Jan 2021, Kewen.Lin wrote:
>
>> Hi Segher/Richard B./Richard S.,
>>
>> Many thanks for your all helps and comments on this!
>>
>> on 2021/1/25 下午3:56, Richard Biener wrote:
>>> On Fri, 22 Jan 2021, Segher Boessenkool wrote:
>>>
On Fri, J
Hi,
This patch merges the previously approved one[1] and its relied patch
made by Segher here[2], it's to make unsigned int vector init go with
rldimi to merge two integers instead of shift and ior.
Segher's patch in [2] is required to make the test case pass,
otherwise the costing for new pseudo
Hi,
I'd like to gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/564758.html
BR,
Kewen
on 2021/2/3 下午2:37, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> This patch merges the previously approved one[1] and its relied patch
> made by Segher here[2], it&#
Hi Segher & Will,
Thanks for your review comments!
on 2021/2/19 上午2:33, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Feb 03, 2021 at 02:37:05PM +0800, Kewen.Lin wrote:
>> This patch merges the previously approved one[1] and its relied patch
>> made by Segher here[2], it's to make unsigned int vec
on 2021/1/27 下午5:43, Kewen.Lin via Gcc-patches wrote:
> on 2021/1/26 下午6:53, Richard Biener wrote:
>> On Tue, 26 Jan 2021, Kewen.Lin wrote:
>>
>>> Hi Segher/Richard B./Richard S.,
>>>
>>> Many thanks for your all helps and comments on this!
>>
on 2021/7/30 下午10:04, Kewen.Lin via Gcc-patches wrote:
> Hi Richi,
>
> on 2021/7/30 下午7:34, Richard Biener wrote:
>> This adds a gather vectorization capability to the vectorizer
>> without target support by decomposing the offset vector, doing
>> sclar loads and then
on 2021/8/2 下午3:09, Richard Biener wrote:
> On Mon, 2 Aug 2021, Kewen.Lin wrote:
>
>> on 2021/7/30 下午10:04, Kewen.Lin via Gcc-patches wrote:
>>> Hi Richi,
>>>
>>> on 2021/7/30 下午7:34, Richard Biener wrote:
>>>> This adds a gather vectorizati
on 2021/8/2 下午5:11, Richard Biener wrote:
> On Mon, 2 Aug 2021, Kewen.Lin wrote:
>
>> on 2021/8/2 下午3:09, Richard Biener wrote:
>>> On Mon, 2 Aug 2021, Kewen.Lin wrote:
>>>
>>>> on 2021/7/30 下午10:04, Kewen.Lin via Gcc-patches wrote:
>>>>>
on 2021/8/3 下午8:08, Richard Biener wrote:
> On Fri, Jul 30, 2021 at 7:20 AM Kewen.Lin wrote:
>>
>> on 2021/7/29 下午4:01, Richard Biener wrote:
>>> On Fri, Jul 23, 2021 at 10:41 AM Kewen.Lin wrote:
on 2021/7/22 下午8:56, Richard Biener wrote:
> On Tue, Jul 20, 2021 at 4:37
> PM Kewe
on 2021/8/4 下午6:01, Richard Biener wrote:
> On Wed, Aug 4, 2021 at 4:36 AM Kewen.Lin wrote:
>>
>> on 2021/8/3 下午8:08, Richard Biener wrote:
>>> On Fri, Jul 30, 2021 at 7:20 AM Kewen.Lin wrote:
on 2021/7/29 下午4:01, Richard Biener wrote:
> On Fri, Jul 23, 2021 at 10:41 AM Kewen.Lin w
Hi,
The existing vec_unpacku_{hi,lo} supports emulated unsigned
unpacking for short and char but misses the support for int.
This patch adds the support for vec_unpacku_{hi,lo}_v4si.
Meanwhile, the current implementation uses vector permutation
way, which requires one extra customized constant ve
on 2021/8/4 下午8:04, Richard Biener wrote:
> On Wed, Aug 4, 2021 at 12:47 PM Kewen.Lin wrote:
>>
>> on 2021/8/4 下午6:01, Richard Biener wrote:
>>> On Wed, Aug 4, 2021 at 4:36 AM Kewen.Lin wrote:
on 2021/8/3 下午8:08, Richard Biener wrote:
> On Fri, Jul 30, 2021 at 7:20 AM Kewen.Lin wro
Hi Bill,
Thanks for the comments!
on 2021/8/6 下午9:10, Bill Schmidt wrote:
> Hi Kewen,
>
> On 8/4/21 9:06 PM, Kewen.Lin wrote:
>> Hi,
>>
>> The existing vec_unpacku_{hi,lo} supports emulated unsigned
>> unpacking for short and char but misses the support for int.
>> This patch adds the support fo
Hi,
This patch is to make prototypes of some Power10 built-in
functions consistent with what's in the documentation, as
well as the vector version. Otherwise, useless conversions
can be generated in gimple IR, and the vectorized versions
will have inconsistent types.
Bootstrapped & regtested on
Hi,
This patch is to add the support to make vectorizer able to
vectorize scalar version of some built-in functions with its
corresponding vector version with Power10 support.
Bootstrapped & regtested on powerpc64le-linux-gnu {P9,P10}
and powerpc64-linux-gnu P8.
Is it ok for trunk?
BR,
Kewen
--
Hi Bill,
Thanks for your prompt review!
on 2021/8/12 上午12:34, Bill Schmidt wrote:
> Hi Kewen,
>
> FWIW, it's easier on reviewers if you include the patch inline instead of as
> an attachment.
>
> On 8/11/21 1:56 AM, Kewen.Lin wrote:
>> Hi,
>>
>> This patch is to add the support to make vectori
Hi Bill,
on 2021/8/12 上午12:24, Bill Schmidt wrote:
> Hi Kewen,
>
> On 8/11/21 12:44 AM, Kewen.Lin wrote:
>> Hi,
>>
>> This patch is to make prototypes of some Power10 built-in
>> functions consistent with what's in the documentation, as
>> well as the vector version. Otherwise, useless conversio
Hi Segher,
Thanks for the review!
on 2021/8/12 下午11:10, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Aug 11, 2021 at 02:56:11PM +0800, Kewen.Lin wrote:
>> * config/rs6000/rs6000.c (rs6000_builtin_md_vectorized_function): Add
>> support for some built-in functions vectorized on Power10.
on 2021/8/12 下午11:51, Segher Boessenkool wrote:
> On Thu, Aug 12, 2021 at 10:10:10AM +0800, Kewen.Lin wrote:
>>> + enum rs6000_builtins vname = RS6000_BUILTIN_COUNT;
>>>
>>> Using this as a flag value looks unnecessary. Is this just being done to
>>> silence a warning?
>>
>> Good question!
Hi,
IIUC, the function vectorizable_bb_reduc_epilogue missed to
consider the cost to extract the final value from the vector
for reduc operations. This patch is to add one time of
vec_to_scalar cost for extracting.
Bootstrapped & regtested on powerpc64le-linux-gnu P9.
The testing on x86_64 and a
Hi Richi,
Thanks for the comments!
on 2021/8/16 下午2:49, Richard Biener wrote:
> On Mon, Aug 16, 2021 at 8:03 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> IIUC, the function vectorizable_bb_reduc_epilogue missed to
>> consider the cost to extract the final value from the vector
>> for reduc operations. T
Hi David,
on 2021/8/19 上午11:26, David Edelsohn via Gcc-patches wrote:
> Hi, Martin
>
> A few PowerPC-specific testcases started failing yesterday on AIX with
> a strange failure mode: the compiler runs out of memory. As you may
> expect from telling you this in an email reply to your patch, I ha
Hi Martin,
on 2021/8/20 上午12:30, Martin Sebor wrote:
> On 8/19/21 9:03 AM, Martin Sebor wrote:
>> On 8/18/21 11:56 PM, Kewen.Lin wrote:
>>> Hi David,
>>>
>>> on 2021/8/19 上午11:26, David Edelsohn via Gcc-patches wrote:
Hi, Martin
A few PowerPC-specific testcases started failing yeste
Hi Richi,
on 2021/8/23 下午10:33, Richard Biener via Gcc-patches wrote:
> This removes --param vect-inner-loop-cost-factor in favor of looking
> at the estimated number of iterations of the inner loop
> when available and otherwise just assumes a single inner
> iteration which is conservative on the
on 2021/8/24 下午9:02, Segher Boessenkool wrote:
> Hi Ke Wen,
>
> On Mon, Aug 09, 2021 at 10:53:00AM +0800, Kewen.Lin wrote:
>> on 2021/8/6 下午9:10, Bill Schmidt wrote:
>>> On 8/4/21 9:06 PM, Kewen.Lin wrote:
The existing vec_unpacku_{hi,lo} supports emulated unsigned
unpacking for short an
on 2021/8/25 上午5:56, Segher Boessenkool wrote:
> On Fri, Aug 13, 2021 at 11:18:46AM +0800, Kewen.Lin wrote:
>> on 2021/8/12 下午11:51, Segher Boessenkool wrote:
>>> It is a bad idea to initialise things unnecessary: it hinders many
>>> optimisations, but much more importantly, it silences warnings wi
on 2021/8/25 上午6:14, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Aug 13, 2021 at 10:34:46AM +0800, Kewen.Lin wrote:
>> on 2021/8/12 下午11:10, Segher Boessenkool wrote:
+ && VECTOR_UNIT_ALTIVEC_OR_VSX_P (in_vmode))
+{
+ machine_mode exp_mode = DImode;
+ machine
Hi Haochen,
on 2021/8/25 下午3:06, HAO CHEN GUI via Gcc-patches wrote:
> Hi,
>
> I refined the patch according to Bill's advice. I pasted the ChangeLog
> and diff file here. If it doesn't work, please let me know. Thanks.
>
> 2021-08-25 Haochen Gui
>
> gcc/
IIUC, this patch is for PR93127,
on 2021/8/11 下午1:44, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> This patch is to make prototypes of some Power10 built-in
> functions consistent with what's in the documentation, as
> well as the vector version. Otherwise, useless conversions
> can be generated in gimple
Hi,
This patch is to extend the existing function find_alignment_op to
check all defintions of base_reg are AND operations with mask -16B
to force the alignment. If all are satifised, it passes all AND
operations and instructions in one vector to recombine_lvx_pattern
and recombine_stvx_pattern,
Hi Segher,
Thanks for the review!
>> * config/rs6000/rs6000-p8swap.c (insn_rtx_pair_t): New type.
>
> Please don't do that. The "first" and "second" are completely
> meaningless. Also, keeping it separate arrays can very well result in
> better machine code, and certainly makes easier to
Hi Hans,
on 2020/9/6 上午10:47, Hans-Peter Nilsson wrote:
> On Tue, 1 Sep 2020, Bin.Cheng via Gcc-patches wrote:
>>> Great idea! With explicitly specified -funroll-loops, it's bootstrapped
>>> but the regression testing did show one failure (the only one):
>>>
>>> PASS->FAIL: gcc.dg/sms-4.c scan-
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546698.html
BR,
Kewen
on 2020/8/31 下午1:49, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> I'd like to gentle ping this since IVOPTs part is already to land.
>
> https://gcc.gnu.org/pipermail/gcc-patches/
Hi Segher,
Thanks for your suggestions!
>> + for (unsigned i = 0; i < and_insns.length (); ++i)
>
> "i++" is used more often, is more traditional.
>
Updated.
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/powerpc/pr97019.c
>> @@ -0,0 +1,82 @@
>> +/* This issue can only exist on littl
Hi,
The commit r11-3230 brings a nice improvement to use full
vectors instead of partial vectors when available. But
it caused some vector with length test cases to fail on
Power.
The failure on gcc.target/powerpc/p9-vec-length-epil-7.c
exposed one issue that: we call function
vect_need_peeling
Hi Richard,
> "Kewen.Lin" writes:
>> Hi,
>>
>> The commit r11-3230 brings a nice improvement to use full
>> vectors instead of partial vectors when available. But
>> it caused some vector with length test cases to fail on
>> Power.
>>
>> The failure on gcc.target/powerpc/p9-vec-length-epil-7.c
>
Hi Richard,
on 2020/9/21 下午2:50, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>> "Kewen.Lin" writes:
Hi,
The commit r11-3230 brings a nice improvement to use full
vectors instead of partial vectors when available. But
it caused some vector with length
Hi Richard,
on 2020/9/22 下午10:34, Richard Sandiford wrote:
> Richard Sandiford writes:
>> I'll try to have a patch ready tomorrow morning European time.
>
> Well, I totally failed to hit that deadline. When testing on Power,
> I saw a couple of extra failures, but I now think they're improvemen
on 2020/9/23 下午7:33, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> on 2020/9/22 下午10:34, Richard Sandiford wrote:
>>> Also, while splitting out the logic that handles epilogues with
>>> constant iterations, I added a check to make sure that we don't
>>> try to use partial vectors to vectorise
Hi,
As the discussion in PR96789, we found that some scalar stmts
which can be eliminated by some passes after SLP, but we still
modeled their costs when trying to SLP, it could impact
vectorizer's decision. One typical case is the case in PR on
target Power.
As Richard suggested there, this pat
Hi Richard,
Thanks for the comments!
> diff --git a/gcc/tree-ssa-loop-ivcanon.c b/gcc/tree-ssa-loop-ivcanon.c
> index 298ab215530..7016f993339 100644
> --- a/gcc/tree-ssa-loop-ivcanon.c
> +++ b/gcc/tree-ssa-loop-ivcanon.c
> @@ -1605,6 +1605,14 @@ pass_complete_unroll::execute (function *fun)
>
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
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,
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_
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 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 latent bug in define_expand vec_s
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_DEF_CFA reg note with
>> fra
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 other direction I am worried that the unspecs
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,
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,
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,
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,
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
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
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
>>>>
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
>> handle option powerpc64 in
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 & Iain!
on 2022/9/30 02:37, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Sep 29, 2022 at 07:25:44PM +0100, Iain Sandoe wrote:
>>> On 29 Sep 2022, at 18:04, Segher Boessenkool
>>> wrote:
>>> On Thu, Sep 29, 2022 at 09:16:33AM +0100, Iain Sandoe wrote:
Which means that we do not rep
on 2022/9/30 01:11, Segher Boessenkool wrote:
> On Thu, Sep 29, 2022 at 01:45:16PM +0800, Kewen.Lin wrote:
>> I found this flag is mainly related to tune setting and spotted that we have
>> some code
>> for tune setting when no explicit cpu is given.
>>
>> ...
>>
>> else
>> {
>> size_
Hi Segher!
on 2022/9/28 22:55, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Aug 24, 2022 at 04:17:55PM +0800, Kewen.Lin wrote:
>> 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 o
Hi Segher,
Thanks for the review comments!
on 2022/9/28 23:22, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Aug 25, 2022 at 01:50:28PM +0800, Kewen.Lin wrote:
>> --- a/gcc/config/rs6000/rs6000-internal.h
>> +++ b/gcc/config/rs6000/rs6000-internal.h
>> @@ -183,10 +183,15 @@ extern tree rs6000_fold
Hi Segher,
on 2022/9/30 04:31, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Aug 24, 2022 at 04:17:07PM +0800, Kewen.Lin wrote:
>> --- a/gcc/config/rs6000/rs6000.cc
>> +++ b/gcc/config/rs6000/rs6000.cc
>> @@ -14771,18 +14771,9 @@ rs6000_print_patchable_function_entry (FILE *file,
>>
Hi Segher!
Thanks for the comments again!
on 2022/10/4 05:15, Segher Boessenkool wrote:
> On Fri, Sep 30, 2022 at 08:15:37PM +0800, Kewen.Lin wrote:
>> on 2022/9/30 01:11, Segher Boessenkool wrote:
+#ifdef OS_MISSING_POWERPC64
+ else if (OS_MISSING_POWERPC64)
+ /* It's unexpe
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 Segher!
on 2022/10/10 21:58, Segher Boessenkool wrote:
> On Mon, Oct 10, 2022 at 10:15:58AM +0800, Kewen.Lin wrote:
>> on 2022/10/4 05:15, Segher Boessenkool wrote:
>>> Right. If If mpowerpc64 is enabled while OS_MISSING_POWERPC64, warn for
>>> that;
>>
>> Currently if option powerpc64 is ena
Hi,
As PR103623 shows, it's a regression failure due to new built-in
function framework, previously we guard __builtin_{un,}pack_{longdouble,
ibm128} built-in functions under hard float, so they are unavailable
with the given configuration. While with new bif infrastructure, it
becomes available
Hi,
As PR103353 shows, we may want to continue to expand a MMA built-in
function like a normal function, even if we have already emitted
error messages about some missing required conditions. As shown in
that PR, without one explicit mov optab on OOmode provided, it would
call emit_move_insn recu
Hi Haochen,
Some minor comments are inlined.
on 2022/3/10 2:31 PM, HAO CHEN GUI via Gcc-patches wrote:
> Hi,
>This patch adds V1TI mode into mode iterator used in vector comparison
> expands.With the patch, both built-ins and direct comparison could generate
> P10 new V1TI comparison instruct
Hi,
PR104482 is one regression about the handlings on different argument
numbers from its prototype of built-in function. Without the patch,
the code only catches the case when argument number is more than the
one of prototype, but it ignores the possibility that the number of
arguments can be mo
Hi,
Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590692.html
BR,
Kewen
on 2022/2/22 10:47 AM, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As PR104024 shows, currently the option -mpower10-fusion isn't guarded
> under -mcpu=power10, so compiler can optim
Hi,
Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590959.html
BR,
Kewen
on 2022/2/28 1:37 PM, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As PR103196 shows, p9-vec-length-full-7.c needs to be adjusted as the
> complete unrolling can happen on some of its
Hi,
Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591147.html
BR,
Kewen
on 2022/3/3 10:11 AM, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As PR103623 shows, it's a regression failure due to new built-in
> function framework, previously we guard __b
Hi,
Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591150.html
BR,
Kewen
on 2022/3/3 4:38 PM, 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 alr
Hi,
As shown in PR104967, for some overload built-in function instance,
if it requires a date type which isn't defined on the target, its
fntype would be initialized as NULL. This patch is to consider
this possibility in function find_instance to avoid ICE.
Bootstrapped and regtested on powerpc6
on 2022/3/23 8:29 PM, David Edelsohn wrote:
> On Wed, Mar 23, 2022 at 5:33 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> As shown in PR104967, for some overload built-in function instance,
>> if it requires a date type which isn't defined on the target, its
>> fntype would be initialized as NULL. This patc
Hi,
Commit r12-7687 exposed one miss optimization chance in function
rs6000_maybe_emit_maxc_minc, for now it only considers comparison
codes GE/GT/LE/LT, but it can support more variants with codes
UNLT/UNLE/UNGT/UNGE by reversing them into the equivalent ones
with GE/GT/LE/LT.
Bootstrapped and r
Hi,
Commit r12-7687 exposed one miss optimization chance in function
rs6000_maybe_emit_maxc_minc, for now it only considers comparison
codes GE/GT/LE/LT, but it can support more variants with codes
UNLT/UNLE/UNGT/UNGE by reversing them into the equivalent ones
with GE/GT/LE/LT.
Bootstrapped and r
Hi Segher,
on 2022/3/27 11:02 PM, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Mar 24, 2022 at 10:00:43AM +0800, Kewen.Lin wrote:
>> Commit r12-7687 exposed one miss optimization chance in function
>> rs6000_maybe_emit_maxc_minc, for now it only considers comparison
>> codes GE/GT/LE/LT, but it ca
on 2022/4/1 10:49 PM, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Apr 01, 2022 at 02:27:14PM +0800, Kewen.Lin wrote:
>> Commit r12-7687 exposed one miss optimization chance in function
>> rs6000_maybe_emit_maxc_minc, for now it only considers comparison
>> codes GE/GT/LE/LT, but it can support mor
Hi,
As PR103353 shows, we may want to continue to expand a MMA built-in
function like a normal function, even if we have already emitted
error messages about some missing required conditions. As shown in
that PR, without one explicit mov optab on OOmode provided, it would
call emit_move_insn recu
on 2022/4/2 5:52 AM, Peter Bergner wrote:
> On 4/1/22 3:50 PM, will schmidt wrote:
>> Is there a testcase, new or existing, that illustrates this error path?
>
> Well, the already existsing test case pr101849.c is where the issue was seen,
> but only when compiled by hand outside of the test harne
Hi,
Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590959.html
This patch is to fix one regressed test case, I guess it still can be
considered for stage 4.
BR,
Kewen
> on 2022/2/28 1:37 PM, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> As PR103196
Hi Segher & Jakub,
Thanks for the comments!
on 2022/4/7 9:00 PM, Jakub Jelinek wrote:
> On Thu, Apr 07, 2022 at 06:09:52AM -0500, Segher Boessenkool wrote:
>> Hi!
>>
>> On Thu, Mar 03, 2022 at 10:11:32AM +0800, Kewen.Lin wrote:
>>> As PR103623 shows, it's a regression failure due to new built-in
Hi,
As PR103623 shows, it's a regression failure due to new built-in
function framework, previously we guard __builtin_{un,}pack_{longdouble,
ibm128} built-in functions under hard float, so they are unavailable
with the given configuration. While with new bif infrastructure, it
becomes available
201 - 300 of 1024 matches
Mail list logo
