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 powerp
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.
Bootstrapp
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
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
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:
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/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 the
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 support DQ fo
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
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 Kewen.Lin wrote:
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
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 sep
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 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
>> fo
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
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
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 m
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
ring about this. It's a good idea to handle this
power8-fusion specially for now.
BR,
Kewen
> Thanks,
> Bill
>
> On 1/5/22 1:34 AM, Kewen.Lin wrote:
>> Hi,
>>
>> This patch is to fix the inconsistent behaviors for non-LTO mode
>> and LTO mode.
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 fun
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 need
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,
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 cor
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* cases,
Hi Uros,
on 2021/11/17 下午3:13, Uros Bizjak wrote:
> On Thu, Nov 11, 2021 at 12:25 PM Kewen Lin wrote:
>>
>> This patch is to fix some non-robust split conditions in some
>> define_insn_and_splits, to make each of them applied on top of
>> the corresponding condition for define_insn part, otherwis
on 2021/11/20 上午6:26, augustine.sterl...@gmail.com wrote:
> On Thu, Nov 11, 2021 at 3:25 AM Kewen Lin wrote:
>> gcc/ChangeLog:
>>
>> * config/xtensa/xtensa.md (movdi_internal, movdf_internal): Fix split
>> condition.
>
> I had been hoping Max would reply (as I'm just doing legacy
Hi,
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 r
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580358.html
BR,
Kewen
>>> on 2021/9/28 下午4:16, Kewen.Lin via Gcc-patches wrote:
>>>> Hi,
>>>>
>>>> This patch follows the discussions here[1][2], where Segher
>>
>>>>> on 2021/9/1 下午2:55, 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 the func
Hi,
As the discussions and the testing result under the main thread, this
patch would be safe.
Ping for this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580357.html
BR,
Kewen
>> on 2021/9/28 下午4:13, Kewen.Lin via Gcc-patches wrote:
>>> Hi,
>>>
>>&
Hi Robin,
on 2021/11/12 下午5:56, Robin Dapp wrote:
> Hi Kewen and Richard,
>
> the attached v3 addresses the comments to v2, among others:
>
> - Rename to load_store where appropriate.
> - Save the adjusted length as a separate control that is used instead
> of loop_len with a bias != 0 and add
Hi,
This patch is to add a test case similar to the one in i386
to add testing coverage for 510.parest_r hotspots.
As evaluated, the emulated gather capability of vectorizer
(r12-2733) can help to speed up SPEC2017 510.parest_r on
Power8/9/10 by 5% to 9% with option sets Ofast unroll and
Ofast lt
on 2021/11/25 下午1:17, Hongtao Liu wrote:
> On Thu, Nov 25, 2021 at 11:21 AM Kewen.Lin via Gcc-patches
> wrote:
>>
>> Hi,
>>
>> This patch is to add a test case similar to the one in i386
>> to add testing coverage for 510.parest_r hotspots.
>>
>>
on 2021/11/27 上午12:24, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Nov 25, 2021 at 11:20:57AM +0800, Kewen.Lin wrote:
>> This patch is to add a test case similar to the one in i386
>> to add testing coverage for 510.parest_r hotspots.
>
>> gcc/testsuite/ChangeLog
Hi Segher,
on 2021/11/30 上午8:16, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Sep 28, 2021 at 04:13:40PM +0800, Kewen.Lin wrote:
>> PR target/102347
>> * config/rs6000/rs6000-call.c (rs6000_builtin_decl): Remove builtin
>> mask check.
>
> (Don'
Hi Segher,
on 2021/11/30 上午6:06, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Sep 28, 2021 at 04:16:04PM +0800, Kewen.Lin wrote:
>> This patch follows the discussions here[1][2], where Segher
>> pointed out the existing way to guard the extra penalized
>> cost for strid
Hi Segher,
Thanks for the review!
on 2021/11/30 上午6:28, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Jun 11, 2021 at 09:16:21PM +0800, Kewen.Lin wrote:
>>>> +/* Should pick up the lowest luid if the references
>>>> + are in the same block.
Hi Haochen,
on 2021/12/1 下午5:01, HAO CHEN GUI via Gcc-patches wrote:
> Hi,
> This patch modifies the combine pattern with a helper -
> change_pseudo_and_mask when recog fails.
> The helper converts a single pseudo to the pseudo AND with a mask if the
> outer operator is IOR/XOR/PLUS
> and the
Hi Mike,
on 2021/12/3 上午8:51, Michael Meissner wrote:
> On Mon, Nov 29, 2021 at 10:57:12AM -0600, Segher Boessenkool wrote:
>> Why are there OPTION_MASKs for separate P10 fusion types here, as well as
>> MASK_P10_FUSION?
>
> Well going back in time, before we used rs6000_isa_flags, we used the de
Hi Segher,
Thanks for the review!
on 2021/11/30 上午12:57, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Sep 01, 2021 at 02:55:51PM +0800, Kewen.Lin wrote:
>> This patch is to fix the inconsistent behaviors for non-LTO mode
>> and LTO mode. As Martin pointed out, c
Hi,
For a function with optimize pragma, it's possible that the target
options change as optimization options change. Now we create one
optimization option node when parsing pragma optimize, but don't
create target option node for possible target option changes. It
makes later processing not det
Hi Segher,
on 2021/12/6 下午9:06, Segher Boessenkool wrote:
> On Fri, Dec 03, 2021 at 11:46:53AM +0800, Kewen.Lin wrote:
>>>> This patch is to fix the inconsistent behaviors for non-LTO mode
>>>> and LTO mode. As Martin pointed out, currently the function
>>>&
on 2021/12/9 上午9:43, Jeff Law wrote:
>
>
> On 12/6/2021 7:15 PM, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> For a function with optimize pragma, it's possible that the target
>> options change as optimization options change. Now we create one
>>
on 2021/12/9 下午11:21, Martin Liška wrote:
> On 12/7/21 03:15, Kewen.Lin wrote:
>> Hi,
>>
>> For a function with optimize pragma, it's possible that the target
>> options change as optimization options change. Now we create one
>> optimization option node w
Hi Jeff,
on 2022/10/12 14:48, 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 incomplete address and can not be put into a .rodata sect
Hi Iain,
on 2022/10/13 18:09, Iain Sandoe wrote:
>
>
>> On 12 Oct 2022, at 09:57, Iain Sandoe wrote:
>>> On 12 Oct 2022, at 09:12, Kewen.Lin wrote:
>>
>>> PR106680 shows that -m32 -mpowerpc64 is different from
>>> -mpowerpc64 -m32, this is d
Hi Will,
Some comments are inline.
on 2022/9/20 00:05, will schmidt wrote:
> [PATCH, rs6000] Tests of ARCH_PWR8 and -mno-vsx option.
>
> Hi,
>
> This adds an assortment of tests to exercise the -mno-vsx option and
> confirm the impacts on the ARCH_PWR8 define.
>
> These are based on and inspir
Hi Will,
Thanks for fixing this, some comments are inline as below.
on 2022/9/20 00:13, will schmidt wrote:
> [PATCH, rs6000] Split TARGET_POWER8 from TARGET_DIRECT_MOVE [PR101865]
>
> Hi,
> The _ARCH_PWR8 define is conditional on TARGET_DIRECT_MOVE,
> and can be disabled by dependent options
Hi!
on 2022/10/19 00:52, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Oct 18, 2022 at 10:17:30AM -0500, will schmidt wrote:
>> On Mon, 2022-10-17 at 13:08 -0500, Segher Boessenkool wrote:
>>> It did not happen in GCC 9 obviously. Do you want to take a
>>> shot? It
>>> doesn't have to be all at o
Hi,
As PR107240 shows, when both the value to be shifted and the
count used for shifting are constants, it doesn't actually
requires a target to support vector shift operations.
This patch is to try fold_build2 for the generation of the
shifted value first, if it's folded, the shift is gone,
othe
Hi,
Currently effective target vect_long_long doesn't have
power specific check, I think it's an oversight. This
is to add the support which checks for has_arch_pwr8,
since we set rs6000_vector_unit[V2DImode] as:
(TARGET_P8_VECTOR) ? VECTOR_P8_VECTOR : VECTOR_NONE;
it means its full support s
Hi Richi,
on 2022/10/19 15:43, Richard Biener wrote:
> On Wed, Oct 19, 2022 at 5:18 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> As PR107240 shows, when both the value to be shifted and the
>> count used for shifting are constants, it doesn't actually
>&g
Hi Haochen,
Sorry for late review, some comments are inline.
on 2022/9/7 15:44, 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. The instructions using DI
Hi Jeff,
Sorry for late review, some comments are inline.
on 2022/8/24 16:13, Jiufu Guo via Gcc-patches wrote:
> Hi,
>
> PR106708 constaint some constants which can be support by li/lis + oris/xoris.
>
> For constant C:
> if ((c & 0x80008000ULL) == 0x8000ULL) or say:
> 32(0)+1(1)+15
Hi,
As PR107338 shows, with the use of widening loads, the
container_type can become a wider type, it causes us to
get wrong shift_n since the BIT_FIELD_REF offset actually
becomes bigger on BE. Taking the case in PR107338 as
example, at the beginning the container type is short and
BIT_FIELD_REF
on 2022/10/24 20:55, Richard Biener wrote:
> On Mon, Oct 24, 2022 at 12:43 PM Kewen.Lin wrote:
>>
>> Hi,
>>
>> As PR107338 shows, with the use of widening loads, the
>> container_type can become a wider type, it causes us to
>> get wrong shift_n since the B
Hi Surya,
on 2022/10/14 01:02, Surya Kumari Jangala via Gcc-patches wrote:
> testsuite: Fix failure in test pr105586.c [PR107171]
>
> The test pr105586.c fails on a big endian system when run in 32bit
> mode. The failure occurs as the test case does not guard against
> unsupported __int128.
>
I
Hi,
The test cases vect-bitfield-read-* requires vector shift
target support, they need one explicit vect_shift effective
target requirement checking. Besides, the vectype for struct
in test cases vect-bitfield-read-{2,4} is vector of long long,
we need to check effective target vect_long_long fo
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
improve overall cycles as normally the latency of vector access
with length in bytes is bigger than
Hi,
This is to fix the failure on powerpc as reported in PR106806,
the test case requires tree ifcvt pass to perform on that loop,
and it relies on masked_load support. The fix is to guard the
expected scan with vect_masked_load effective target.
As tested on powerpc64{,le}-linux-gnu and aarch64
Hi,
As PR99888 and its related show, the current support for
-fpatchable-function-entry on powerpc ELFv2 doesn't work
well with global entry existence. For example, with one
command line option -fpatchable-function-entry=3,2, it got
below w/o this patch:
.LPFE1:
nop
nop
Hi,
As PR106322 shows, in some cases for some vector type whose
TYPE_MODE is a scalar integral mode instead of a vector mode,
it's possible to obtain wrong target support information when
querying with the scalar integral mode. For example, for the
test case in PR106322, on ppc64 32bit vectorizer
Hi Jeff,
on 2022/8/12 14:39, Jiufu Guo via Gcc-patches wrote:
> Hi,
>
> As a comment in
> https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599556.html
>
> Those splitters call rs6000_emit_set_const directly, and the replacements
> are never used. Using (pc) would be less misleading.
Since
on 2022/8/12 19:14, Richard Biener wrote:
> On Fri, Aug 12, 2022 at 11:41 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> As PR106322 shows, in some cases for some vector type whose
>> TYPE_MODE is a scalar integral mode instead of a vector mode,
>> it's possibl
Hi Richi,
>>
>> Yes, but you just missed the RC for 12.2 so please wait until after GCC 12.2
>> is released and the branch is open again. The testcase looks mightly
>> complicated
>> so fallout there might be well possible as well ;) I suppose it wasn't
>> possible
>> to craft a simple C testca
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598748.html
BR,
Kewen
on 2022/7/25 14:26, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As the failure of test case gcc.target/powerpc/pr92398.p9-.c in
> PR106345 shows, some test sources for some power
Hi,
Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598601.html
BR,
Kewen
on 2022/7/20 17:30, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> Commit r12-6679-g7ca1582ca60dc8 made vectorizer accept one
> unroll factor to be applied to vectorization factor when
> vecto
Hi,
Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594699.html
BR,
Kewen
>>
>>> on 2022/5/13 13:29, Kewen.Lin via Gcc-patches wrote:
>>>> Hi,
>>>>
>>>> PR105485 exposes that new builtin function framework doesn't handle
>
Hi,
Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-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 cas
Hi,
Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597286.html
BR,
Kewen
>
> on 2022/6/27 10:47, Kewen.Lin via Gcc-patches wrote:
>> Hi Segher!
>>
>> on 2022/6/25 00:49, Segher Boessenkool wrote:
>>> Hi!
>>>
>>> On Fri
on 2022/7/11 11:42, Kewen.Lin wrote:
> on 2022/6/15 14:20, Kewen.Lin wrote:
>> Hi Honza,
>>
>> Thanks for the comments! Some replies are inlined below.
>>
>> on 2022/6/14 19:37, Jan Hubicka wrote:
>>>> Hi,
>>>>
>>>> Function opt
Hi Segher,
Thanks for the review!
on 2022/8/16 05:30, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jun 27, 2022 at 10:47:26AM +0800, Kewen.Lin wrote:
>> on 2022/6/25 00:49, Segher Boessenkool wrote:
>> Many thanks for all the further explanation above! The attached
Hi Xionghu,
Thanks for the updated version of patch, some comments are inlined.
on 2022/8/11 14:15, Xionghu Luo wrote:
>
>
> On 2022/8/11 01:07, Segher Boessenkool wrote:
>> On Wed, Aug 10, 2022 at 02:39:02PM +0800, Xionghu Luo wrote:
>>> On 2022/8/9 11:01, Kewen.Lin
Hi,
As PR99888 and its related show, the current support for
-fpatchable-function-entry on powerpc ELFv2 doesn't work
well with global entry existence. For example, with one
command line option -fpatchable-function-entry=3,2, it got
below w/o this patch:
.LPFE1:
nop
nop
Hi Segher,
Thanks for the review!
on 2022/8/19 01:34, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Aug 18, 2022 at 10:12:48AM +0800, Kewen.Lin wrote:
>> As PR99888 and its related show, the current support for
>> -fpatchable-function-entry on powerpc ELFv2 doesn't work
Hi Haochen,
on 2022/8/19 10:35, HAO CHEN GUI wrote:
> Hi,
>
> This patch is for internal issue1136. It changes insn condition from
> TARGET_64BIT to TARGET_POWERPC64 for VSX scalar extract/insert instructions.
> These instructions all use DI registers and can be invoked with -mpowerpc64
> in a
on 2022/8/24 13:11, HAO CHEN GUI wrote:
> Hi Segher,
>
> On 23/8/2022 下午 10:26, Segher Boessenkool wrote:
>> Hi!
>>
>> On Fri, Aug 19, 2022 at 10:35:54AM +0800, HAO CHEN GUI wrote:
>>> --- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-0.c
>>> +++ b/gcc/testsuite/gcc.target/powerpc/bfp/
Hi Segher,
on 2022/8/23 22:33, Segher Boessenkool wrote:
> On Fri, Aug 19, 2022 at 10:40:10AM +0800, Kewen.Lin wrote:
>> Since you proposed to update the documentation, I'm thinking if we can
>> reconsider Fangrui's proposal in the PR which Alan seconded: Put precedi
Hi,
As discussed in PR98125, -fpatchable-function-entry with
SECTION_LINK_ORDER support doesn't work well on powerpc64
ELFv1 because the filled "Symbol" in
.section name,"flags"o,@type,Symbol
sits in .opd section instead of in the function_section
like .text or named .text*.
Since we already
Hi,
As PR106516 shows, we can get unexpected gimple outputs for
function thud on some target which supports modulus operation
for vector int. This patch introduces one effective target
vect_int_mod for it, then adjusts the test case with it.
Tested on x86_64-redhat-linux and powerpc64{,le}-linux
on 2022/8/25 11:37, HAO CHEN GUI wrote:
> Hi,
>
> On 24/8/2022 下午 1:24, Kewen.Lin wrote:
>> Could you try to test with dg-options "-mdejagnu-cpu=power9 -mpowerpc64" all
>> the time, but still
>> having that has_arch_ppc64 effective target on aix?
>>
&g
Hi,
As PR99888 and its related show, the current support for
-fpatchable-function-entry on powerpc ELFv2 doesn't work
well with global entry existence. For example, with one
command line option -fpatchable-function-entry=3,2, it got
below w/o this patch:
.LPFE1:
nop
nop
on 2022/8/24 22:01, Segher Boessenkool wrote:
> On Wed, Aug 24, 2022 at 03:30:51PM +0800, Kewen.Lin wrote:
>> on 2022/8/23 22:33, Segher Boessenkool wrote:
>> I thought if we can consider [1] and updated the documentation similarly
>> like "For PowerPC with the ELFv2
on 2022/8/26 10:42, HAO CHEN GUI wrote:
> Hi David,
>
> On 25/8/2022 下午 10:01, David Edelsohn wrote:
>> On Thu, Aug 25, 2022 at 1:22 AM Kewen.Lin wrote:
>>>
>>> on 2022/8/25 11:37, HAO CHEN GUI wrote:
>>>> Hi,
>>>>
>>>> On 24
Hi Haochen,
on 2022/8/26 15:29, HAO CHEN GUI wrote:
> Hi,
> This patch changes the sequence of test directives for 3 cases. Originally,
> these 3 cases got failed or unsupported on some platforms, as their target
> selector checks depend on compiling options.
Maybe it's good to say more in the
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598748.html
BR,
Kewen
> on 2022/7/25 14:26, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> As the failure of test case gcc.target/powerpc/pr92398.p9-.c in
>> PR106345 shows, some test sources
Hi,
Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598601.html
BR,
Kewen
>
> on 2022/7/20 17:30, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> Commit r12-6679-g7ca1582ca60dc8 made vectorizer accept one
>> unroll factor to be applied to vectorizat
gt;> on 2022/5/13 13:29, Kewen.Lin via Gcc-patches wrote:
>>>>> Hi,
>>>>>
>>>>> PR105485 exposes that new builtin function framework doesn't handle
>>>>> unresolved overloaded builtin function well. With new builtin
>>>>
Hi,
Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595208.html
I think this is a reasonable fix, the behavior is consistent with what we have
in
the previous built-in framework, I'm going to push this a week later if no
objections. :)
BR,
Kewen
> Hi,
>
> As PR104
on 2022/8/15 16:33, Kewen.Lin via Gcc-patches wrote:
> on 2022/7/11 11:42, Kewen.Lin wrote:
>> on 2022/6/15 14:20, Kewen.Lin wrote:
>>> Hi Honza,
>>>
>>> Thanks for the comments! Some replies are inlined below.
>>>
>>> on 2022/6/14 19
Hi Peter,
Thanks for the patch! Some comments are inline as below.
on 2022/8/27 11:50, Peter Bergner via Gcc-patches wrote:
> When we expand an MMA disassemble built-in with C++ using a pointer that
> is casted to a valid MMA type, the type isn't passed down to the expand
> machinery and we end
Hi,
Commit r12-2266 updated the scanned assembly content from
"{\mlvx\M|\mlxv\M|\mlxvd2x\M}"
to
"{\mp?lxv\M|\mlxv\M|\mlxvd2x\M}"
for the test case pr86731-fwrapv-longlong.c unexpectedly.
It's meant to update "lxv" to "p?lxv" and should leave the
"lvx" unchanged. So this is to fix the typ
Hi,
Test case bswap64-4.c suffers the issue as its comments:
/* On some versions of dejagnu this test will fail when
biarch testing with RUNTESTFLAGS="--target_board=unix
'{-m64,-m32}'" due to -m32 being added on the command
line after the dg-options -mpowerpc64.
common/config/rs6000/
Hi Segher & Peter,
Thanks for your reviews!
on 2022/8/31 23:12, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 05:33:21PM +0800, Kewen.Lin wrote:
>> It's meant to update "lxv" to "p?lxv" and should leave the
>> "lvx" unchanged. So thi
+ if (TREE_TYPE (TREE_TYPE (src_ptr)) != src_type)
>>>
>>> This line looks unexpected, the former is type char while the latter is
>>> type __vector_pair *.
>>>
>>> I guess you meant to compare the type of pointer type like:
>>>
>>>TREE_TYPE (TREE_TYPE (src_ptr)) != TREE_TYPE (s
>>> ...and of course, now I can't recreate that issue at all and the
>>> ptr_vector_*_type use work fine now. Strange! ...so ok, changed.
>>> Maybe the behavior changed since my PR106017 fix went in???
>>
>> That is my best guess as well. But, how did that help this test?
>
> It didn't. :-) Du
on 2022/8/31 22:13, Peter Bergner wrote:
> On 8/31/22 4:33 AM, Kewen.Lin wrote:
>> @@ -1,7 +1,8 @@
>> /* { dg-do compile { target { powerpc*-*-* } } } */
>> /* { dg-skip-if "" { powerpc*-*-aix* } } */
>> -/* { dg-options "-O2 -mpowerpc64"
Hi Segher and Peter,
Thanks a lot for your insightful comments on this.
I just read through all discussions and plan to give a
try as replied below.
on 2022/8/31 23:24, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 05:33:28PM +0800, Kewen.Lin wrote:
>> Test case bswap64-4.c su
Hi Haochen,
on 2022/9/1 13:30, HAO CHEN GUI wrote:
> Hi,
> This patch changes the sequence of test directives for 3 test cases.
> Originally, these 3 cases got failed or unsupported on some platforms, as
> their effective target checks depend on compiling options.
>
Thanks for the updated patc
Hi Segher,
on 2022/9/1 22:57, Segher Boessenkool wrote:
> On Thu, Sep 01, 2022 at 04:57:59PM +0800, Kewen.Lin wrote:
>> on 2022/8/31 22:13, Peter Bergner wrote:
>>> On 8/31/22 4:33 AM, Kewen.Lin wrote:
>>>> @@ -1,7 +1,8 @@
>>>> /* { dg-do compile { ta
901 - 1000 of 1615 matches
Mail list logo
