on 2023/4/12 20:47, Kewen.Lin wrote:
> Hi Segher & Jeff,
>
> on 2023/4/11 23:13, Segher Boessenkool wrote:
>> On Tue, Apr 11, 2023 at 05:40:09PM +0800, Kewen.Lin wrote:
>>> on 2023/4/11 17:14, guojiufu wrote:
Thanks for raising this concern.
The behavior to check about bif on
Hi!
on 2023/4/12 19:37, juzhe.zh...@rivai.ai wrote:
> Thank you. Richard. >> I think that already works for them (could be
> misremembering). >> However, IIUC, they have no special instruction to
> calculate the >> length (unlike for RVV), and so it's open-coded using
> vect_get_len.
>
>
Hi Segher & Jeff,
on 2023/4/11 23:13, Segher Boessenkool wrote:
> On Tue, Apr 11, 2023 at 05:40:09PM +0800, Kewen.Lin wrote:
>> on 2023/4/11 17:14, guojiufu wrote:
>>> Thanks for raising this concern.
>>> The behavior to check about bif on FLOAT128_HW and emit an error message for
>>>
Hi Jeff,
on 2023/4/11 17:14, guojiufu wrote:
> Hi Kewen,
>
> Thanks a lot for your very helpful comments!
>
> On 2023-04-10 17:26, Kewen.Lin wrote:
>> Hi Jeff,
>>
>> on 2023/4/10 10:09, Jiufu Guo via Gcc-patches wrote:
>>> Hi,
>>>
>>> In this test case (float128-cmp2-runnable.c), the
Hi Jeff,
on 2023/4/10 10:09, Jiufu Guo via Gcc-patches wrote:
> Hi,
>
> In this test case (float128-cmp2-runnable.c), the instruction
> xscmpexpqp is used to support a few builtins e.g.
> __builtin_vsx_scalar_cmp_exp_qp_eq on _Float128.
> This instruction handles the whole 128bits of the vector,
Hi Alexandre,
on 2023/4/7 12:37, Alexandre Oliva wrote:
> On Apr 6, 2023, "Kewen.Lin" wrote:
>
>> on 2023/4/6 13:20, Alexandre Oliva wrote:
>>> I confirm I observe the problem with gcc-12 targeting ppc64-vx7r2,
>>> containing the backported patch, and that the loop is vectorized,
>>> failing
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, but that is no good for a compile
> error,
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
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
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
>>> full-word stores, even without any vector instruction
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 wide, as on vxworks, the rs6000 backend
>>> defines
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:
*
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
>> endianness. Currently the
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
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
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
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
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
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,
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.
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 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
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 +
Hi Alexander,
Thanks a lot for your comments and suggestions!
on 2023/3/20 16:03, Alexander Monakov wrote:
>
> On Mon, 20 Mar 2023, Kewen.Lin wrote:
>
>> Hi,
>
> Hi. Thank you for the thorough analysis. Since I analyzed
> PR108519, I'd like to offer my comments.
>
>> As PR108273 shows, when
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 current handling in
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
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,
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
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
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
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 Segher,
on 2023/3/9 22:55, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Mar 09, 2023 at 05:30:53PM +0800, Kewen.Lin wrote:
>> on 2023/3/9 07:01, Peter Bergner via Gcc-patches wrote:
>>> PR109073 shows a problem where GCC 11 and GCC 10 do not accept a const
>>> __vector_pair pointer operand to
Hi Peter,
on 2023/3/9 07:01, Peter Bergner via Gcc-patches wrote:
> PR109073 shows a problem where GCC 11 and GCC 10 do not accept a const
> __vector_pair pointer operand to some MMA builtins, which GCC 12 and later
> correctly accept. Fixed here by initializing the builtins to accept const
>
Hi Haochen,
on 2023/3/3 20:54, Tobias Burnus wrote:
> Hi Haochen,
>
> On 03.03.23 10:56, HAO CHEN GUI via Gcc-patches wrote:
>> Sure, I will merge it into the patch and do the regression test.
> Thanks :-)
>> Additionally, Kewen suggested:
Since this test case is powerpc only, I think it
Hi,
According to Haochen's finding in [1], currently ppc-fortran.exp
doesn't support Fortran specific warning or error messages well.
By looking into it, it's due to that gfortran uses some different
warning/error prefixes as follows:
set gcc_warning_prefix "\[Ww\]arning:"
set
Hi,
As PR108727 shows, when cleanup code called by the stack
unwinder calls function _Unwind_Resume, it goes via plt
stub like:
function .plt_call._Unwind_Resume:
=> 0x10003580 <+0>: std r2,40(r1)
0x10003584 <+4>: ld r12,-31760(r2)
Hi Haochen,
on 2023/3/1 15:09, HAO CHEN GUI wrote:
> Hi,
> The patch escalates the failure when Hollerith constant to real conversion
> fails in native_interpret_expr. It finally reports an "Unclassifiable
> statement" error.
>
> The patch of pr95450 added a verification for
Hi,
Test cases scalar-test-data-class-1[45].c adopts type __int128
which requires to check int128 effective target, otherwise the
testing on them will fail at -m32. This patch is to add int128
effective target requirement.
Tested on powerpc64-linux-gnu P7/P8/P9 and
powerpc64le-linux-gnu P9/P10.
Hi,
Compiled with cpu type Power9 or later, GCC generates
xxspltib rather than vspltis*, so adjust the test
case scanning content accordingly.
Tested on powerpc64-linux-gnu P7/P8/P9 and
powerpc64le-linux-gnu P9/P10.
I'm going to push this soon if no objections.
BR,
Kewen
-
PR
Hi,
On BE, the extracted index for the leftmost element is 0
rather than 1, adjust the test case accordingly.
Tested on powerpc64-linux-gnu P7/P8/P9 and
powerpc64le-linux-gnu P9/P10.
I'm going to push this soon if no objections.
BR,
Kewen
-
PR testsuite/108810
Hi,
The built-in function scalar_test_neg_qp is under stanza
ieee128-hw, that is TARGET_FLOAT128_HW. Since we don't
have float128 hardware support on 32-bit as follows:
if (TARGET_FLOAT128_HW && !TARGET_64BIT)
{
if ((rs6000_isa_flags_explicit & OPTION_MASK_FLOAT128_HW) != 0)
error
Hi,
Two test cases scalar-test-data-class-12.c and vec-test-data-class-9.c
fail on Power9 BE testing at -m32, they adopts a built-in function
scalar_insert_exp which requires powerpc64 support. This patch
is to make them to check has_arch_ppc64 effective target requirement.
Tested on
Hi Haochen,
on 2023/2/20 10:04, HAO CHEN GUI wrote:
> Hi,
> This patch merges two "vsldoi" insns when their sources are the
> same. Particularly, it is simplified to be one move if the total
> shift is multiples of 16 bytes.
>
> Bootstrapped and tested on powerpc64-linux BE and LE with no
>
Hi Mike,
on 2023/2/3 13:49, Michael Meissner wrote:
> This patch is a repost of a patch:
>
> | Date: Thu, 19 Jan 2023 11:37:27 -0500
> | Subject: [PATCH] PR target/107299: Fix build issue when long double is IEEE
> 128-bit
> | Message-ID:
>
> This patch updates the IEEE 128-bit types used in
Hi Mike,
on 2023/2/3 13:53, Michael Meissner wrote:
> This patch 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 128-bit. The old code also did
Hi Segher,
Thanks for the comments!
on 2023/2/19 20:12, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Feb 17, 2023 at 11:33:16AM +0800, Kewen.Lin wrote:
>> on 2023/2/16 23:10, Segher Boessenkool wrote:
>>> No, you are right that the semantics are pretty much the same. Please
>>> just keep
Hi,
As PR108807 exposes, the current handling in function
rs6000_expand_vector_set_var_p9 doesn't take care of big
endianness. Currently the function is to rotate the
target vector by moving element to-be-set to element 0,
set element 0 with the given val, then rotate back. To
get the
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
Hi Segher,
Thanks for the comments!
on 2023/2/16 23:10, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Feb 16, 2023 at 08:06:02PM +0800, Kewen.Lin wrote:
>> on 2023/2/16 19:14, Segher Boessenkool wrote:
>>> On Thu, Feb 16, 2023 at 05:23:40PM +0800, Kewen.Lin wrote:
This patch is to fix the
Hi Segher,
Thanks for the review comments!
on 2023/2/16 19:14, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Feb 16, 2023 at 05:23:40PM +0800, Kewen.Lin wrote:
>> This patch is to fix the handling with one more pre-insn
>> vpopcntb. It also fixes an oversight having V8HI in VEC_IP,
>> replaces
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
on 2023/2/13 21:57, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>
>> on 2023/1/27 19:08, Richard Sandiford via Gcc-patches wrote:
>>> PR96373 points out that a predicated SVE loop currently converts
>>> trapping unconditional ops into unpredicated vector ops. Doing
>>> the
Hi Richard,
on 2023/1/27 19:08, Richard Sandiford via Gcc-patches wrote:
> PR96373 points out that a predicated SVE loop currently converts
> trapping unconditional ops into unpredicated vector ops. Doing
> the operation on inactive lanes can then raise an exception.
>
> As discussed in the PR
Hi Segher,
I guessed that this patch escaped from your radar. :)
As Jakub asked the status in PR106069, I applied this attached patch from
Xionghu
to the latest trunk, re-tested it and confirmed that it's still bootstrapped and
regtested on powerpc64-linux-gnu P8 and powerpc64le-linux-gnu P9
Hi Mike,
Thanks for the comments!
on 2023/1/18 04:57, Michael Meissner wrote:
> On Mon, Jan 16, 2023 at 05:39:04PM +0800, Kewen.Lin wrote:
>> Hi,
>>
>> Now we will check optimize_function_for_speed_p (cfun) for
>> TARGET_SAVE_TOC_INDIRECT if it's implicitly enabled. But
>> the effect of
Hi,
To keep the previous refactoring patch not need to
re-generate fusion.md and make the review easier,
I didn't merge this patch into the previous one.
But I think this one can help to make the subroutine
gen_logical_addsubf_scalar more clear, by separating
logical-logical and add-logical
Hi,
As Segher suggested in [1], this patch is to refactor the
script genfusion.pl for generating fusion.md.
It mainly consists of:
1) Add main subroutine, which calls several backbone
subroutines, hope it can show the skeleton clearly.
2) Encapsulate copyright and top comments emission
Hi Segher,
on 2023/1/16 23:24, Segher Boessenkool wrote:
> On Mon, Jan 16, 2023 at 09:05:38PM +0800, Kewen.Lin wrote:
>>> The *_ok things should only be used for features that can be disabled
>>> during configuration, or features that we *want* users to be able to
>>> turn off (like FP, VMX, VSX,
Hi,
As Andrew pointed out in PR108396, there is one typo in
rs6000-overload.def on built-in function vec_vsubcuq:
[VEC_VSUBCUQ, vec_vsubcuqP, __builtin_vec_vsubcuq]
"vec_vsubcuqP" should be "vec_vsubcuq", this typo caused
us to define vec_vsubcuqP in rs6000-vecdefines.h instead
of
Hi Segher!
on 2023/1/16 18:40, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jan 16, 2023 at 05:20:56PM +0800, Kewen.Lin wrote:
>> on 2023/1/16 16:49, Segher Boessenkool wrote:
+/* { dg-require-effective-target powerpc_p9modulo_ok } */
>>>
>>> Please use a saner selector? If one doesn't
Hi,
Now we will check optimize_function_for_speed_p (cfun) for
TARGET_SAVE_TOC_INDIRECT if it's implicitly enabled. But
the effect of -msave-toc-indirect is actually to save the
TOC in the prologue for indirect calls rather than inline,
it's also good for optimize_function_for_size? So this
Hi Segher,
Thanks for the review comments!
on 2023/1/16 16:49, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jan 16, 2023 at 04:33:36PM +0800, Kewen.Lin wrote:
>> PR108348 shows one special case that MMA opaque types are
>> used in function arguments and treated as pass by reference,
>> it
Hi,
As Honza pointed out in [1], the current uses of function
optimize_function_for_speed_p in rs6000_option_override_internal
are too early, since the query results from the functions
optimize_function_for_{speed,size}_p could be changed later due
to profile feedback and some function attributes
Hi,
PR108348 shows one special case that MMA opaque types are
used in function arguments and treated as pass by reference,
it results in one copying from argument to a temp variable,
since this copying happens before rs6000_function_arg check,
it can cause ICE without MMA support then. This
on 2023/1/6 17:26, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As PR108272 shows, there are some invalid uses of MMA opaque
> types in inline asm statements. This patch is to teach the
> function rs6000_opaque_type_invalid_use_p for inline asm,
> check and error any invalid
Hi,
As PR108240 shows, some options like -mmodulo can enable some
flags implicitly including OPTION_MASK_VSX. But the enabled
flag can conflict with some existing setting like soft float,
it would result in some unexpected cases and consequent ICE.
Actually there are already some checkings for
Hi,
When testing one patch which adds a fortran test case into
test bucket powerpc/ppc-fortran/, I found one unexpected
failure on a non-PowerPC target. It's due to that
ppc-fortran.exp does not exit early if the testing target
isn't a PowerPC target. This patch is to make it exit
immediately
on 2023/1/6 17:28, Kewen.Lin via Gcc-patches wrote:
> Hi Pat,
>
> on 2023/1/6 03:30, Pat Haugen wrote:
>> On 1/4/23 3:20 AM, Kewen.Lin via Gcc-patches wrote:
>>> diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
>>> index 88c865b6b4b..6fa084
Hi Pat,
on 2023/1/6 03:30, Pat Haugen wrote:
> On 1/4/23 3:20 AM, Kewen.Lin via Gcc-patches wrote:
>> diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
>> index 88c865b6b4b..6fa084c0807 100644
>> --- a/gcc/config/rs6000/rs6000.cc
>> +++ b/
Hi,
Before r13-4894, if 64 bit is explicitly specified, option
powerpc64 is explicitly enabled too; while if 64 bit is
implicitly enabled and there is no explicit setting for
option powerpc64, option powerpc64 is eventually enabled
or not would rely on the default value of the used cpu.
It's
Hi,
As PR108272 shows, there are some invalid uses of MMA opaque
types in inline asm statements. This patch is to teach the
function rs6000_opaque_type_invalid_use_p for inline asm,
check and error any invalid use of MMA opaque types in input
and output operands.
Bootstrapped and regtested on
on 2023/1/4 22:02, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Jan 04, 2023 at 08:15:03PM +0800, Kewen.Lin wrote:
>> on 2023/1/4 18:46, Segher Boessenkool wrote:
@@ -25604,7 +25602,9 @@ rs6000_call_aix (rtx value, rtx func_desc, rtx
tlsarg, rtx cookie)
/* Can we optimize
Hi Segher,
Thanks for the comments.
on 2023/1/4 18:46, Segher Boessenkool wrote:
> On Wed, Jan 04, 2023 at 05:20:14PM +0800, Kewen.Lin wrote:
>> As Honza pointed out in [1], the current uses of function
>> optimize_function_for_speed_p in rs6000_option_override_internal
>> are too early, since
Hi,
We noticed this issue when Segher reviewed the patch for
PR104024. When there is no explicit setting for option
-mpower10-fusion, we enable OPTION_MASK_P10_FUSION for
TARGET_POWER10. But it's not right, it should honour
tuning setting instead.
This patch is to fix it accordingly, it's
Hi,
As Honza pointed out in [1], the current uses of function
optimize_function_for_speed_p in rs6000_option_override_internal
are too early, since the query results from the functions
optimize_function_for_{speed,size}_p could be changed later due
to profile feedback and some function attributes
Hi Segher,
on 2022/12/24 04:26, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Oct 12, 2022 at 04:12:21PM +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 rs6000_handle_option.
Hi Joseph,
on 2022/12/22 05:40, Joseph Myers wrote:
> On Wed, 21 Dec 2022, Segher Boessenkool wrote:
>
>>> --- a/gcc/tree.cc
>>> +++ b/gcc/tree.cc
>>> @@ -9442,15 +9442,6 @@ build_common_tree_nodes (bool signed_char)
>>>if (!targetm.floatn_mode (n, extended).exists ())
>>> continue;
Hi Segher,
on 2022/12/22 05:24, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Dec 21, 2022 at 05:02:17PM +0800, Kewen.Lin wrote:
>> This a different attempt from Mike's approach[1][2] to fix the
>> issue in PR107299.
>
> Ke Wen, Mike: so iiuc with this patch applied all three of Mike's
> patches
Hi,
This a different attempt from Mike's approach[1][2] to fix the
issue in PR107299. With option -mabi=ieeelongdouble specified,
type long double (and __float128) and _Float128 have the same
mode TFmode, but they have different type precisions, it causes
the assertion to fail in function
Hi Segher,
on 2022/12/20 21:19, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Dec 19, 2022 at 02:13:49PM +0800, Kewen.Lin wrote:
>> on 2022/12/15 06:29, Segher Boessenkool wrote:
>>> On Wed, Nov 30, 2022 at 04:30:13PM +0800, Kewen.Lin wrote:
--- a/gcc/config/rs6000/genfusion.pl
+++
Hi,
The hunk for setting flag OPTION_MASK_P10_FUSION locates wrongly
between the if and else if block for OPTION_MASK_MMA. This is
to fix this oversight accordingly.
Bootstrapped and regtested on powerpc64-linux-gnu P8 and
powerpc64le-linux-gnu P9 and P10.
IMO this is obvious, already
on 2022/12/21 02:56, Segher Boessenkool wrote:
> On Wed, Dec 14, 2022 at 07:21:20PM +0800, Kewen.Lin wrote:
>> I'm going to push this next week if no objections.
>
> Please do?
>
Thanks! Committed in r13-4814-g282462b39584ae.
BR,
Kewen
on 2022/12/20 20:14, Jakub Jelinek wrote:
> On Mon, Dec 19, 2022 at 04:11:59PM +0800, Kewen.Lin wrote:
>> In function fold_convert_const_real_from_real, when the modes of
>> two types involved in fp conversion are the same, we can simply
>> take it as copy, rebuild with the exactly same
Hi Richi,
Thanks for the comments!
on 2022/12/19 16:49, Richard Biener wrote:
> On Mon, Dec 19, 2022 at 9:12 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> In function fold_convert_const_real_from_real, when the modes of
>> two types involved in fp conversion are the same, we can simply
>> take it as
Hi,
In function fold_convert_const_real_from_real, when the modes of
two types involved in fp conversion are the same, we can simply
take it as copy, rebuild with the exactly same TREE_REAL_CST and
the target type. It is more efficient and helps to avoid possible
unexpected signalling bit
Hi Segher,
Thanks for the review comments!
on 2022/12/15 06:29, Segher Boessenkool wrote:
> On Wed, Nov 30, 2022 at 04:30:13PM +0800, Kewen.Lin wrote:
>> As PR104024 shows, the option -mpower10-fusion isn't guarded by
>> -mcpu=power10, it causes compiler to fuse for some patterns
>> even without
Hi Honza,
Thanks for the comments.
on 2022/12/14 21:22, Jan Hubicka wrote:
>>> PR middle-end/105818
>>>
>>> gcc/ChangeLog:
>>>
>>> * predict.cc (optimize_function_for_size_p): Further check
>>> optimize_size of fun->decl when it is valid but no cgraph node.
>>>
>>>
on 2022/12/14 18:33, Jakub Jelinek wrote:
> On Wed, Dec 14, 2022 at 06:11:26PM +0800, Kewen.Lin wrote:
>>> The hacks with different precisions of powerpc 128-bit floating types are
>>> very unfortunate, it is I assume because the middle-end asserted that scalar
>>> floating point types with
>> I bet the above workaround in generic code was added for a reason, it would
>> surprise me if _Float128 worked at all without that hack.
>
> OK, I'll have a look at those nan failures soon.
By investigating the exposed NaN failures, I found it's due to that it wants
to convert _Float128 type
Hi,
Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607527.html
BR,
Kewen
on 2022/11/30 16:30, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> Function optimize_function_for_size_p returns OPTIMIZE_SIZE_NO
> if fun->decl is not null but no cgraph no
Hi,
Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607526.html
BR,
Kewen
on 2022/11/30 16:30, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As PR104024 shows, the option -mpower10-fusion isn't guarded by
> -mcpu=power10, it causes compiler to fuse for some pat
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
Hi,
Gentle ping this series:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607146.html
BR,
Kewen
on 2022/11/24 17:15, Kewen Lin wrote:
> Hi,
>
> Following Segher's suggestion, this patch series is to rework
> function rs6000_emit_vector_compare for vector float and int
> in multiple
Hi,
As PR106736 shows, it's unexpected to use __vector_quad and
__vector_pair types without MMA support, it would cause ICE
when expanding the corresponding assignment. We can't guard
these built-in types registering under MMA support as Peter
pointed out in that PR, because the registering is
Hi Jeff,
on 2022/12/12 09:38, Jiufu Guo via Gcc-patches wrote:
> Hi,
>
> For constant C:
> If '(c & 0x8000ULL) == 0x8000ULL' or say:
> 32(1) || 16(x) || 1(1) || 15(x), using "li; xoris" would be ok.
>
> If '(c & 0x80008000ULL) == 0x8000ULL' or say:
> 32(0) ||
Hi Jakub,
Thanks for the comments!
on 2022/12/14 17:36, Jakub Jelinek wrote:
> On Wed, Dec 14, 2022 at 04:46:07PM +0800, Kewen.Lin via Gcc-patches wrote:
>> on 2022/12/6 19:27, Kewen.Lin via Gcc-patches wrote:
>>> Hi Mike,
>>>
>>> Thanks for fixing t
Hi Jeff,
on 2022/12/12 09:44, Jiufu Guo via Gcc-patches wrote:
> Hi,
>
> Compare with previous patch, this patch updates accoding to comments; fixes
> conflicts with trunk, and recheck bootstrap
> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607333.html
>
> For a complicate 64bit
on 2022/12/6 19:27, Kewen.Lin via Gcc-patches wrote:
> 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
on 2022/12/13 14:14, Michael Meissner wrote:
> On Mon, Dec 12, 2022 at 06:20:14PM +0800, Kewen.Lin wrote:
>> Without or with patch #1, the below ICE in libgcc exists, the ICE should have
>> nothing to do with the special handling for building_libgcc in patch #1. I
>> think patch #2 which makes
on 2022/12/12 11:23, HAO CHEN GUI wrote:
> Hi Kewen,
>
> 在 2022/12/8 16:47, Kewen.Lin 写道:
>> This documentation update reminds me of that the current prototype of
>> __ieee128
>> variant can be:
>>
>> unsigned int scalar_extract_exp (__ieee128 source);
>>
>> type unsigned int is enough for the
201 - 300 of 1022 matches
Mail list logo
