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
Hi,
Bootstrapped and regress-tested on powerpc64-linux-gnu P8 and
powerpc64le-linux-gnu P8, P9 and P10.
Pushed this as r13-720-g149d04ccbb908b3a251485b43faf204752942b9f.
---
As PR105627 exposes, pass analyze_swaps should skip debug
insn when doing unionfind_union. One debug insn can use
Hi Piotr,
on 2022/5/23 05:36, Piotr Kubaj wrote:
> Ping.
>
> FreeBSD has already enabled sanitizers in its base system in
> https://cgit.freebsd.org/src/commit/?id=f5024381ac16ba43d37a8bd32d54c27f6a6afa66
> The upstream (LLVM) patch was reviewed by a couple of people already.
>
> Our
Hi,
Move pr83660.C to g++.target. As comment #3 of PR83660,
renaming it to c isn't one option.
This test case isn't tested before, so this brings back
the test coverage.
Committed as r13-619-g297a69068ddfe2.
BR,
Kewen
-
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr83660.C:
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
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
argument number is less than the one of function prototype, but
it misses the case that the argument
Hi Haochen,
on 2022/5/16 13:22, HAO CHEN GUI wrote:
> Hi,
>This patch adds a combine pattern for "CA minus one". As CA only has two
> values (0 or 1), we could convert following pattern
> (sign_extend:DI (plus:SI (reg:SI 98 ca)
> (const_int -1 [0x]
>
Hi,
PR105485 exposes that new builtin function framework doesn't handle
unresolved overloaded builtin function well. With new builtin
function support, we don't have builtin info for any overloaded
rs6000_gen_builtins enum, since they are expected to be resolved to
one specific instance. So
on 2022/5/13 04:16, Segher Boessenkool wrote:
> Hi Piotr,
>
> On Tue, May 03, 2022 at 12:21:12PM +0200, pku...@freebsd.org wrote:
>> FreeBSD/powerpc* has feenableexcept() defined in fenv.h header.
>
> Declared, not defined. These are required to be real functions (on all
> platforms that have
Hi Haochen,
on 2022/5/13 09:07, HAO CHEN GUI wrote:
> Hi,
>This patch adds a combine pattern for "CA minus one". As CA only has two
> values (0 or 1), we could convert following pattern
> (sign_extend:DI (plus:SI (reg:SI 98 ca)
> (const_int -1 [0x]
>
Hi Piotr,
Thanks for doing this, some comments are inlined.
on 2022/5/11 07:32, Piotr Kubaj via Gcc-patches wrote:
> Is there anything more required?
>
> On 22-05-03 12:33:43, Piotr Kubaj wrote:
>> Here are gmake check-gfortran results requested by FX.
>>
>> Before patching:
>>
on 2022/1/27 20:51, Segher Boessenkool wrote:
> On Thu, Jan 27, 2022 at 07:24:53PM +0800, Kewen.Lin wrote:
>> on 2022/1/27 上午1:57, Segher Boessenkool wrote:
>>> I like your original patch better. But for stage 1, sorry.
>>
>> Thanks Segher! Is it ok to commit it t
Hi Segher,
on 2022/5/10 20:27, Segher Boessenkool wrote:
> Hi guys,
>
> On Mon, May 09, 2022 at 12:05:51PM +0800, Kewen.Lin wrote:
>> on 2022/5/9 09:54, HAO CHEN GUI wrote:
>>> This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000.
>>> Tests s
Hi Haochen,
Thanks for the patch, some comments are inlined.
on 2022/5/9 09:54, 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.
>
>
on 2022/5/5 16:09, Richard Biener via Gcc-patches wrote:
> On Thu, May 5, 2022 at 10:07 AM HAO CHEN GUI via Gcc-patches
> wrote:
>>
>> Hi,
>>This patch skips constant folding for fmin/max when either argument
>> is sNaN. According to C standard,
>>fmin(sNaN, sNaN）= qNaN, fmin(sNaN, NaN) =
Hi,
Add myself as PowerPC port co-maintainer and to DCO section. Pushed below as
r13-127.
ChangeLog:
* MAINTAINERS: Add myself as PowerPC port co-maintainer and to DCO
section.
---
MAINTAINERS | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS
on 2022/4/27 8:46 PM, David Edelsohn wrote:
> On Wed, Apr 27, 2022 at 8:22 AM Segher Boessenkool
> wrote:
>>
>> Hi!
>>
>> Thank you for doing this testcase.
>>
>> On Wed, Apr 27, 2022 at 06:29:07PM +0800, Kewen.Lin wrote:
>>> As discussed
Hi,
As discussed in PR105334, this patch is to add the test coverage for
the two recent fixes r12-8091 and r12-8226 from Segher, aix is skipped
since it takes soft-float and long-double-128 incompatible.
I noticed the referred test case pack02.c skips if powerpc*-*-darwin*,
but it's for do-run
on 2022/4/26 11:25 PM, Segher Boessenkool wrote:
> On Tue, Apr 26, 2022 at 05:16:18PM +0200, Jakub Jelinek wrote:
>> Hi!
>>
>> On Fri, Apr 15, 2022 at 04:08:15PM +0800, Kewen.Lin via Gcc-patches wrote:
>>> As PR105271 shows, __builtin_altivec_neg_v2di requires opt
Hi,
As PR105271 shows, __builtin_altivec_neg_v2di requires option
-mpower8-vector as its pattern expansion relies on subv2di which
has guard VECTOR_UNIT_P8_VECTOR_P (V2DImode). This fix is to move
the related lines for __builtin_altivec_neg_v2di to the section
of stanza power8-vector.
Hi,
The test case pr105250.c is like its related pr105140.c, which
suffers the error with message like "{AltiVec,vector} argument
passed to unprototyped" on powerpc and s390. So like commits
r12-8025 and r12-8039, this fix is to add the dg-skip-if for
powerpc*-*-* and s390*-*-*.
Tested on
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
argument number is less than the one of function prototype, but
it misses the case that the argument
on 2022/4/13 3:11 AM, Segher Boessenkool wrote:
> On Tue, Apr 12, 2022 at 10:02:06AM +0800, Kewen.Lin wrote:
>> on 2022/4/11 11:42 PM, Segher Boessenkool wrote:
>>> On Mon, Apr 11, 2022 at 04:29:40PM +0800, Kewen.Lin wrote:
>>>> Nice, I confirmed this makes I
on 2022/4/11 11:42 PM, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Apr 11, 2022 at 04:29:40PM +0800, Kewen.Lin wrote:
>> on 2022/4/9 1:31 AM, Segher Boessenkool wrote:
>>> On Fri, Apr 08, 2022 at 10:09:44AM +0800, Kewen.Lin wrote:
>>> For me it fails during com
Hi Segher,
on 2022/4/9 1:31 AM, Segher Boessenkool wrote:
> On Fri, Apr 08, 2022 at 10:09:44AM +0800, Kewen.Lin wrote:
>> As Jakub noted here, we don't have the soft-float support for both m32 and
>> m64
>> before, as the bifs are always guarded under hard-float previous
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
on 2022/4/8 10:34 PM, Segher Boessenkool wrote:
> Hi!
>
> Thanks for investigating.
>
> On Fri, Apr 08, 2022 at 03:25:51PM +0800, Kewen.Lin wrote:
>> on 2022/4/8 3:29 AM, Segher Boessenkool wrote:
>>> On Thu, Apr 07, 2022 at 09:19:51AM -0500, will schmidt wrote:
&g
on 2022/4/8 4:04 PM, Jakub Jelinek wrote:
> On Fri, Apr 08, 2022 at 03:09:00PM +0800, Kewen.Lin wrote:
>> + /* Let's ignore all error messages about built-in function
>> + unsupported due to soft-float, since they are not test
>> + points here (this ca
Hi Will,
on 2022/4/7 10:19 PM, will schmidt wrote:
> On Mon, 2022-02-28 at 13:37 +0800, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
...
>> -
>> PR testsuite/103196
>>
>> gcc/testsuite/ChangeLog:
>>
>> * gcc.target/powerpc/p9-vec-le
Hi!
on 2022/4/8 3:29 AM, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Apr 07, 2022 at 09:19:51AM -0500, will schmidt wrote:
>> On Mon, 2022-02-28 at 13:37 +0800, Kewen.Lin via Gcc-patches wrote:
>>> As PR103196 shows, p9-vec-length-full-7.c needs to be adjusted as the
&g
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 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 r
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
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
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
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/G
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
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
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
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
>&
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
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,
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 __builti
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
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 optimize s
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
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
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
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 PR103196 shows, p9-vec-length-full-7.c needs to be adjusted as the
complete unrolling can happen on some of its loops. This patch is to
use pragma "GCC unroll 0" to disable all possible loop unrollings.
Hope it can help the case not that fragile.
There are some other p9-vec-length*
Hi,
As PR104024 shows, currently the option -mpower10-fusion isn't guarded
under -mcpu=power10, so compiler can optimize some patterns unexpectedly.
As the option is undocumented, this patch just simply unmasks it.
For some define_insns in fusion.md which have constraint v, they don't
have the
on 2022/2/22 上午9:11, HAO CHEN GUI wrote:
>
> Kewen,
> Thanks so much for your advice.
>
> On 21/2/2022 下午 5:42, Kewen.Lin wrote:
>> Hi Haochen,
>>
>> Some minor comments are inlined.
>>
>> on 2022/2/16 下午4:42, HAO CHEN GUI via Gcc-patches wrote:
&g
Hi Haochen,
Some minor comments are inlined.
on 2022/2/16 下午4:42, HAO CHEN GUI via Gcc-patches wrote:
> Hi,
>This patch enables absolute jump tables on PPC AIX and Linux. For AIX, the
> jump
> table is placed in data section. For Linux, it is placed in RELRO section when
> relocation is
Hi Michael,
on 2022/2/9 上午11:27, Michael Meissner via Gcc-patches wrote:
> Reset -mpower8-fusion for power9 inlining power8 functions, PR 102059.
>
> This patch is an attempt to make a much simpler patch to fix PR target/102059
> than the previous patch.
>
> It just fixes the issue that if a
Hi Segher,
Thanks for the comments!
on 2022/2/7 下午3:53, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Jan 05, 2022 at 03:34:41PM +0800, Kewen.Lin wrote:
>> This patch is to fix the inconsistent behaviors for non-LTO mode
>> and LTO mode. As Martin pointed out, c
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587635.html
BR,
Kewen
>> on 2022/1/5 下午3:34, Kewen.Lin via Gcc-patches wrote:
>>> Hi,
>>>
>>> This patch is to fix the inconsistent behaviors for non-LTO mode
>>> and L
on 2022/1/28 上午1:17, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Jan 27, 2022 at 07:21:33PM +0800, Kewen.Lin wrote:
>> PR target/103627
>> * config/rs6000/rs6000.cc (rs6000_option_override_internal): Disable
>> MMA if !TARGET_VSX.
>>
>> gcc/te
Hi Segher,
on 2022/1/27 上午6:42, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Dec 23, 2021 at 10:12:19AM +0800, Kewen.Lin wrote:
>> PR target/103627
>> * config/rs6000/rs6000.c (rs6000_option_override_internal): Move the
>> hunk affecting VSX and ALTIV
Hi Segher,
on 2022/1/27 上午6:19, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Dec 23, 2021 at 10:09:27AM +0800, Kewen.Lin wrote:
>> 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
on 2022/1/27 上午1:57, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Jan 26, 2022 at 10:26:45AM +0800, Kewen.Lin wrote:
>> on 2022/1/14 上午12:31, David Edelsohn wrote:
>> Yeah, but IMHO it still can confuse new comers at first glance.
>
> Yes, or at least cause to read (we
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 which use
VSX register, but we don't have a
on 2022/1/26 下午3:28, Richard Biener wrote:
> On Wed, Jan 26, 2022 at 3:15 AM Kewen.Lin via Gcc-patches
> wrote:
>>
>> Gentle ping:
>>
>> https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587309.html
>
> OK.
>
Thanks Richi! Rebased, re-teste
on 2022/1/14 上午12:31, David Edelsohn wrote:
> On Thu, Jan 13, 2022 at 7:28 AM Kewen.Lin wrote:
>>
>> 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 Ke
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587635.html
BR,
Kewen
>
> on 2022/1/5 下午3:34, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> This patch is to fix the inconsistent behaviors for non-LTO mode
>> and LTO mode. As Martin point
Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587449.html
BR,
Kewen
> 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 suppor
Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587311.html
BR,
Kewen
> 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
Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587310.html
BR,
Kewen
> 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 cl
Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587309.html
BR,
Kewen
> 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
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587635.html
BR,
Kewen
on 2022/1/5 下午3:34, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> This patch is to fix the inconsistent behaviors for non-LTO mode
> and LTO mode. As Martin pointed out, currently
on 2022/1/19 上午5:34, Segher Boessenkool wrote:
> On Tue, Jan 18, 2022 at 11:57:32AM +, Richard Sandiford wrote:
>> "Kewen.Lin" writes:
>>>>PR tree-optimization/104015
>>>>* gcc.dg/vect/slp-perm-9.c: Adjust.
>>>>* gcc.targ
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,
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/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 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/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 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
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,
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 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 s
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
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/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 requireme
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
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
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
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 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
701 - 800 of 1393 matches
Mail list logo
