on 2022/12/9 06:04, Michael Meissner wrote:
> On Wed, Dec 07, 2022 at 03:55:41PM +0800, Kewen.Lin wrote:
>> Hi Mike,
>>
>> on 2022/12/7 14:44, Michael Meissner wrote:
>>> On Tue, Dec 06, 2022 at 05:36:54PM +0800, Kewen.Lin wrote:
Hi Mike,
Thanks for fixing this!
Could you h
on 2022/12/8 15:43, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> on 2022/12/7 20:55, Richard Sandiford wrote:
>>> "Kewen.Lin" writes:
Hi Richard,
on 2022/12/7 17:16, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi,
>>
>> In the recent discussion on how to
Hi Haochen,
on 2022/12/8 11:08, HAO CHEN GUI wrote:
> Hi,
> This patch enables "have_cbranchcc4" on rs6000 by defining
> a "cbranchcc4" expander. "have_cbrnachcc4" is a flag in ifcvt.cc
> to indicate if branch by CC bits is invalid or not. With this
> flag enabled, some branches can be optimized
Hi Haochen,
Thanks for the update, some comments are inlined as below.
on 2022/12/2 15:03, HAO CHEN GUI wrote:
> Hi,
> For scalar extract/insert instructions, exponent field can be stored in a
> 32-bit register. So this patch changes the mode of exponent field from DI to
> SI so that these inst
on 2022/12/7 20:55, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>
>> on 2022/12/7 17:16, Richard Sandiford wrote:
>>> "Kewen.Lin" writes:
Hi,
In the recent discussion on how to make some built-in type only valid for
some target features efficiently[1], Andre
Hi Richard,
on 2022/12/7 17:16, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi,
>>
>> In the recent discussion on how to make some built-in type only valid for
>> some target features efficiently[1], Andrew mentioned this patch which he
>> made previously (Thanks!). I confirmed it can help
Hi Mike,
on 2022/12/7 14:44, Michael Meissner wrote:
> On Tue, Dec 06, 2022 at 05:36:54PM +0800, Kewen.Lin wrote:
>> Hi Mike,
>>
>> Thanks for fixing this!
>>
>> Could you help to elaborate why we need to disable it during libgcc building?
>
> When you are building libgcc, you are building the __
on 2022/12/7 13:24, HAO CHEN GUI wrote:
> Hi Kewen,
> Thanks so much for your review comments. I will fix them.
>
> 在 2022/12/7 11:06, Kewen.Lin 写道:
>> Does this issue which relies on the fix for generic part make bootstrapping
>> fail?
>> If no, how many failures it can cause? I'm thinking if
Hi Haochen,
on 2022/12/6 13:44, HAO CHEN GUI wrote:
> Hi,
> This patch enables "have_cbranchcc4" on rs6000 by defining
> a "cbranchcc4" expander. "have_cbrnachcc4" is a flag in ifcvt.cc
> to indicate if branch by CC bits is invalid or not. With this
> flag enabled, some branches can be optimized
Hi,
In the recent discussion on how to make some built-in type only valid for
some target features efficiently[1], Andrew mentioned this patch which he
made previously (Thanks!). I confirmed it can help rs6000 related issue,
and noticed PR99657 is still opened, so I think we still want this to
be
Hi Mike,
Thanks for fixing this, some comments are inlined below.
on 2022/11/2 10:42, Michael Meissner wrote:
> This patch fixes the issue that GCC cannot build when the default long double
> is IEEE 128-bit. It fails in building libgcc, specifically when it is trying
> to buld the __mulkc3 func
Hi Mike,
Thanks for fixing this!
on 2022/11/2 10:40, Michael Meissner wrote:
> This function reworks how the complex multiply and divide built-in functions
> are
> done. Previously we created built-in declarations for doing long double
> complex
> multiply and divide when long double is IEEE 1
on 2022/12/1 20:16, guojiufu wrote:
> On 2022-12-01 15:10, Jiufu Guo via Gcc-patches wrote:
>> Hi Kewen,
>>
>> 在 12/1/22 2:11 PM, Kewen.Lin 写道:
>>> on 2022/12/1 13:35, Jiufu Guo wrote:
Hi Kewen,
Thanks for your quick and insight review!
在 12/1/22 1:17 PM, Kewen.Lin 写道:
on 2022/12/1 13:35, Jiufu Guo wrote:
> Hi Kewen,
>
> Thanks for your quick and insight review!
>
> 在 12/1/22 1:17 PM, Kewen.Lin 写道:
>> Hi Jeff,
>>
>> on 2022/12/1 09:36, Jiufu Guo wrote:
>>> Hi,
>>>
>>> This patch just uses sext_hwi to replace the expression like:
>>> ((value & 0xf..f) ^ 0x80..0)
on 2022/12/1 13:17, Kewen.Lin via Gcc-patches wrote:
> Hi Jeff,
>
> on 2022/12/1 09:36, Jiufu Guo wrote:
>> Hi,
>>
>> This patch just uses sext_hwi to replace the expression like:
>> ((value & 0xf..f) ^ 0x80..0) - 0x80..0 for rs6000.cc and rs6000.md.
>&g
Hi Jeff,
on 2022/12/1 09:36, Jiufu Guo wrote:
> Hi,
>
> This patch just uses sext_hwi to replace the expression like:
> ((value & 0xf..f) ^ 0x80..0) - 0x80..0 for rs6000.cc and rs6000.md.
>
> Bootstrap & regtest pass on ppc64{,le}.
> Is this ok for trunk?
You didn't say it clearly but I guesse
Hi Jeff,
on 2022/12/1 09:36, Jiufu Guo wrote:
> Hi,
>
> Function rs6000_emit_set_const/rs6000_emit_set_long_const are only invoked
> from
> two "define_split"s where the target operand is limited to gpc_reg_operand or
> int_reg_operand, then the operand must be REG_P.
> And in rs6000_emit_set_co
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603350.html
BR,
Kewen
on 2022/10/12 16:12, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> PR106680 shows that -m32 -mpowerpc64 is different from
> -mpowerpc64 -m32, this is determined by the way how we
>
Hi,
Function optimize_function_for_size_p returns OPTIMIZE_SIZE_NO
if fun->decl is not null but no cgraph node is available for it.
As PR105818 shows, this could cause unexpected consequence. For
the case in PR105818, when parsing bar decl in function foo, the
cfun is the function structure for f
Hi,
As PR104024 shows, the option -mpower10-fusion isn't guarded by
-mcpu=power10, it causes compiler to fuse for some patterns
even without power10 support and then causes ICE unexpectedly,
this patch is to simply unmask it without power10 support, not
emit any warnings as this option is undocume
Add more experts in CC.
on 2022/11/23 10:54, HAO CHEN GUI wrote:
> Hi,
> I want to enable "have_cbranchcc4" on rs6000. But not all combinations of
> comparison codes and sub CC modes are benefited to generate cbranchcc4 insns
> on rs6000. There is an predicate for operand0 of cbranchcc4 to bypas
Hi Richard,
on 2022/11/24 17:24, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi,
>>
>> As the test case in PR107412 shows, we can fold IFN .LEN_{LOAD,
>> STORE} into normal vector load/store if the given length is known
>> to be equal to the length of the whole vector. It would help to
>>
Hi Segher,
on 2022/11/25 23:46, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Nov 25, 2022 at 09:21:21PM +0800, Jiufu Guo wrote:
>> "Kewen.Lin" writes:
>>> on 2022/9/15 16:30, Jiufu Guo wrote:
For a complicate 64bit constant, blow is one instruction-sequence to
build:
lis 9,0x800
Hi Jeff,
Sorry for the late review.
on 2022/9/15 16:30, Jiufu Guo wrote:
> Hi,
>
> For a complicate 64bit constant, blow is one instruction-sequence to
> build:
> lis 9,0x800a
> ori 9,9,0xabcd
> sldi 9,9,32
> oris 9,9,0xc167
> ori 9,9,0xfa16
>
> while we can also u
Hi Haochen,
Sorry for the late reply.
on 2022/11/7 14:45, HAO CHEN GUI wrote:
> Hi,
> For scalar extract/insert instructions, exponent field can be stored in a
> 32-bit register. So this patch changes the mode of exponent field from DI to
> SI. So these instructions can be generated in a 32-bit
Hi Jeff,
Sorry for the late reply.
on 2022/10/26 19:40, Jiufu Guo wrote:
> Hi,
>
> PR106708 constaint some constants which can be support by li/lis + oris/xoris.
typo?
for "li/lis + oris/xoris", I interpreted it into four combinations:
li + oris, lis + oris, li + xoris,
Hi Haochen,
Sorry for the late review.
on 2022/10/11 15:38, HAO CHEN GUI wrote:
> Hi,
> This patch modifies the help function which generates permute index for
> vector byte reversion and generates permute index directly for little endian
> targets. It saves one "xxlnor" instructions on P8 litt
Hi Richard,
on 2022/11/23 00:08, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>
>> Many thanks for your review comments!
>>
>>>>> on 2022/8/24 16:17, Kewen.Lin via Gcc-patches wrote:
>>>>>> Hi,
Hi Haochen,
on 2022/11/22 13:12, HAO CHEN GUI wrote:
> Hi Kewen,
>
> 在 2022/11/22 11:11, Kewen.Lin 写道:
>> Maybe we can adjust prepare_cmp_insn to fail if the constructed cbranchcc4
>> pattern doesn't satisfy the predicate of operand 0 rather than to assert.
>> It's something like:
>>
>> if (!insn
Hi Haochen,
Thanks for the explanation.
on 2022/11/21 14:18, HAO CHEN GUI wrote:
> Hi Segher,
>
> 在 2022/11/18 20:18, Segher Boessenkool 写道:
>> I don't think we should pretend we have any conditional jumps the
>> machine does not actually have, in cbranchcc4. When would this ever be
>> useful?
Hi Richard,
Many thanks for your review comments!
>>> on 2022/8/24 16:17, Kewen.Lin via Gcc-patches wrote:
>>>> Hi,
>>>>
>>>> As discussed in PR98125, -fpatchable-function-entry with
>>>> SECTION_LINK_ORDER support doesn't wo
Hi Segher,
on 2022/11/18 23:10, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Nov 17, 2022 at 02:59:00PM +0800, Kewen.Lin wrote:
>> on 2022/11/17 02:44, Segher Boessenkool wrote:
>>> On Wed, Nov 16, 2022 at 02:48:25PM +0800, Kewen.Lin wrote:
* config/rs6000/rs6000.cc (rs6000_emit_vector_com
Hi Segher,
Thanks for the comments!
on 2022/11/17 02:58, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Nov 16, 2022 at 02:51:04PM +0800, Kewen.Lin wrote:
>> The current handlings in rs6000_emit_vector_compare is a bit
>> complicated to me, especially after we emit vector float
>> comparison insn w
Hi Segher,
Thanks for the comments!
on 2022/11/17 02:44, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Nov 16, 2022 at 02:48:25PM +0800, Kewen.Lin wrote:
>> * config/rs6000/rs6000.cc (rs6000_emit_vector_compare_inner): Remove
>> float only comparison operators.
>
> Why? Is that correct
Hi,
As Robin spotted, my recent commit r13-3716 caused an ICE
on s390 if vector access with length is enabled there (his
patch for the enablement hasn't been committed yet). The
failure is caused by one stupid typo, the bias on s390 is
-1, so the assertion should use tree_fits_shwi_p rather
than
Hi,
The current handlings in rs6000_emit_vector_compare is a bit
complicated to me, especially after we emit vector float
comparison insn with the given code directly. This patch is
to refine the handlings for vector integer comparison operators,
it becomes not recursive, and we don't need the he
Hi,
All kinds of vector float comparison operators have been
supported in one rtl comparison pattern as vector.md, we can
just emit an rtx comparison insn with the given comparison
operator in function rs6000_emit_vector_compare instead of
checking and handling the reverse condition cases.
This i
on 2022/11/10 11:30, Kewen.Lin wrote:
> on 2022/11/9 15:56, Eric Botcazou wrote:
>>> The previous testings on powerpc64{,le}-linux-gnu covered language Go, but
>>> not Ada. I re-tested it with languages c,c++,fortran,objc,obj-c++,go,ada
>>> on powerpc64le-linux-gnu, the result looked good. Both x
Hi,
Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600190.html
Any comments are highly appreciated.
BR,
Kewen
on 2022/9/28 13:41, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600190.html
>
&
on 2022/11/9 15:56, Eric Botcazou wrote:
>> The previous testings on powerpc64{,le}-linux-gnu covered language Go, but
>> not Ada. I re-tested it with languages c,c++,fortran,objc,obj-c++,go,ada
>> on powerpc64le-linux-gnu, the result looked good. Both x86 and aarch64
>> cfarm machines which I us
Hi Richi and Eric,
Thanks for your reviews and comments!
on 2022/11/8 18:37, Eric Botcazou wrote:
>> It looks reasonable - OK if the others CCed have no comments.
>
> My only comment is that it needs to be tested with languages enabling -fnon-
> call-exceptions by default (Ada & Go), if not alre
Hi,
After prologue and epilogue generation, the judgement on whether
one memory access onto stack frame may trap or not could change,
since we get more exact stack information by now.
As PR90259 shows, some memory access becomes impossible to trap
any more after prologue and epilogue generation,
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 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,
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 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
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 BIT_FIELD_REF offset actually
>> becomes b
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
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 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 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
>> requires a target to support vector shift operation
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,
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!
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 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 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 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 determined by the way how we
>>> handle option powerpc
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 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,
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!
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 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 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/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
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 & 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
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!
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
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
>>>>
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
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
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,
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,
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 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 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 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,
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
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,
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_
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 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
on 2022/9/9 15:25, Richard Biener wrote:
> On Fri, Sep 9, 2022 at 8:51 AM Kewen.Lin wrote:
>>
>> Hi Richi,
>>
>> Thanks for the review comments!
>>
>> on 2022/9/8 15:36, Richard Biener wrote:
>>>
>>>
Am 08.09.2022 um 07:53 schrieb Kewen.Lin :
Hi,
As PR106833 shows, cv-qua
Hi Richi,
Thanks for the review comments!
on 2022/9/8 15:36, Richard Biener wrote:
>
>
>> Am 08.09.2022 um 07:53 schrieb Kewen.Lin :
>>
>> Hi,
>>
>> As PR106833 shows, cv-qualified opaque type can cause ICE
>> during LTO. It exposes that we missd to handle OPAQUE_TYPE
>> well in type verifica
Hi,
As PR106833 shows, cv-qualified opaque type can cause ICE
during LTO. It exposes that we missd to handle OPAQUE_TYPE
well in type verification. As Richi pointed out, also
assuming that target will always define TYPE_MAIN_VARIANT
and TYPE_CANONICAL for opaque type, this patch is to check
both
Hi!
> +
> + /* Use paddi for the low 32 bits. */
> + if (ud2 != 0 && ud1 != 0 && can_use_paddi)
> + emit_move_insn (dest, gen_rtx_PLUS (DImode, dest,
> + GEN_INT ((ud2 << 16) | ud1)));
> +
> + /* Use oris, ori for low 32 bits.
Hi Segher,
Gentle ping this patch as you wanted empty TU issue to be fixed
first at the discussion [1]. Thanks in advance for your time!
[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600927.html
BR,
Kewen
on 2022/7/25 14:26, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
&g
on 2022/9/1 22:17, Peter Bergner wrote:
> On 9/1/22 3:29 AM, Kewen.Lin wrote:
>>> I have no idea why ptr_vector_*_type would behave differently here than
>>> build_pointer_type (vector_*_type_node). Using the build_pointer_type()
>>> fixed it for me, so that's why I went with it. :-) Maybe this i
on 2022/9/3 01:44, Segher Boessenkool wrote:
> On Fri, Sep 02, 2022 at 08:51:01AM +0800, Kewen.Lin wrote:
>> on 2022/9/1 23:04, Segher Boessenkool wrote:
>>> On Thu, Sep 01, 2022 at 05:05:44PM +0800, Kewen.Lin wrote:
Without any explicit -mpowerpc64 (and -mno-), I think we all agree
that
on 2022/9/3 01:36, Segher Boessenkool wrote:
> On Fri, Sep 02, 2022 at 08:50:52AM +0800, Kewen.Lin wrote:
>> on 2022/9/1 22:57, Segher Boessenkool wrote:
>>> These two are independent, but apparently we have a bug here, which will
>>> make what you did malfunction in some cases -- the test will not
on 2022/9/2 11:23, HAO CHEN GUI wrote:
> Hi Kewen,
>
> On 1/9/2022 下午 5:34, Kewen.Lin wrote:
>> Thanks for the updated patch!
>>
>> I just found that it seems all the three test cases suffer the empty
>> TU error issue from those has_arch* effective target checks?
>>
>> If yes, it looks we don't n
Hi Jeff,
Thanks for the patch, some comments on nits are inline.
on 2022/9/1 11:24, Jiufu Guo wrote:
> Hi,
>
> As mentioned in PR106550, since pli could support 34bits immediate, we could
> use less instructions(3insn would be ok) to build 64bits constant with pli.
>
> For example, for constant
Hi Segher,
on 2022/9/1 23:04, Segher Boessenkool wrote:
> On Thu, Sep 01, 2022 at 05:05:44PM +0800, Kewen.Lin wrote:
>>> On Wed, Aug 31, 2022 at 05:33:28PM +0800, Kewen.Lin wrote:
>>> *Should* -mpowerpc64 be disabled by -m32?
>>
>> I think the reason to disable -mpowerpc64 at -m32 is that we ha
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 { target { powerpc*-*-* } } } */
/* { dg-ski
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 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 suffers the iss
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" } */
>> /* { dg-require-effective-target ilp32 } */
>> +/
>>> ...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
+ 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
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 this is to fix the typo accordingly.
>>
>> I'll push this so
301 - 400 of 1024 matches
Mail list logo
