Hi,
on 2024/4/30 15:18, HAO CHEN GUI wrote:
> Hi,
> It's the first patch of a series of patches optimizing CC modes on
> rs6000.
>
> bcd insns set all four bits of a CR field. But it has different single
> bit reverse behavior than CCFP's. The forth bit of bcd cr fields is used
> to indict
Hi Richi and Joseph,
on 2024/5/24 20:23, Richard Biener wrote:
> On Fri, May 24, 2024 at 12:20 PM Kewen.Lin wrote:
>> btw, the attached patch is bootstrapped and regtested on
>> powerpc64-linux-gnu and powerpc64le-linux-gnu with all
>> languages on, cross cc1 built we
on 2024/5/28 20:09, Richard Biener wrote:
> On Tue, May 28, 2024 at 9:09 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> on 2024/5/27 20:54, Richard Biener wrote:
>>> On Mon, May 27, 2024 at 11:37 AM HAO CHEN GUI wrote:
>>>>
>>>> Hi,
>>>
Hi,
on 2024/5/27 20:54, Richard Biener wrote:
> On Mon, May 27, 2024 at 11:37 AM HAO CHEN GUI wrote:
>>
>> Hi,
>> This patch adds an optab for __builtin_isfinite. The finite check can be
>> implemented on rs6000 by a single instruction. It needs an optab to be
>> expanded to the certain
Hi Haochen,
on 2024/5/27 15:22, HAO CHEN GUI wrote:
> Hi Kewen,
> Thanks for your comments.
>
> 在 2024/5/27 11:18, Kewen.Lin 写道:
>> Does this require "This pattern is not allowed to FAIL."?
>>
>> I guess yes? Since if it's decided to go with this pat
Hi,
on 2024/5/25 20:13, Alexandre Oliva wrote:
> On Apr 27, 2023, Alexandre Oliva wrote:
>
>> On Apr 14, 2023, Alexandre Oliva wrote:
>>> On Mar 23, 2023, Alexandre Oliva wrote:
This patch introduces infrastructure for targets to add an offset to
the label issued after the call_insn
Hi,
on 2024/5/20 16:15, HAO CHEN GUI wrote:
> Hi,
> This patch adds an optab for __builtin_isfinite. The finite check can be
> implemented on rs6000 by a single instruction. It needs an optab to be
> expanded to the certain sequence of instructions.
>
> The subsequent patches will implement
Hi,
on 2024/4/22 18:11, Alexandre Oliva wrote:
> Ping?-ish
> https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619678.html
>
> It's that time of the year again. The good news is that this is the
> last patch in my ppc*-vxworks7* set ;-)
>
> On May 25, 2023, Segher Boessenkool wrote:
>
>> On
Hi,
on 2024/4/22 17:38, Alexandre Oliva wrote:
> Ping?
> https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566530.html
> (modified version follows)
Segher originated this test case, I was expecting he can chime in this. :)
>
>
> We've observed failures of this test on powerpc
Hi Carl,
on 2024/5/25 04:18, Carl Love wrote:
> Kewen:
>
> On 5/14/24 01:43, Kewen.Lin wrote:
>> Hi,
>>
>> on 2024/4/20 05:17, Carl Love wrote:
>>> rs6000, Remove __builtin_vsx_xvcvspsxws built-in
>>>
>>> The built-in __builtin_vsx
Hi,
on 2024/5/24 02:21, Carl Love wrote:
>
>
> On 5/13/24 22:37, Kewen.Lin wrote:
>> Hi,
>>
>> on 2024/4/20 05:18, Carl Love wrote:
>>> rs6000, remove __builtin_vsx_xvcmpeqsp built-in
>>>
>>> The built-in __builtin_vsx_xvcmpeqs
Hi Joseph and Richi,
on 2024/5/13 21:18, Joseph Myers wrote:
> On Mon, 13 May 2024, Kewen.Lin wrote:
>
>>> In fact replacing all of X_TYPE_SIZE with a single hook might be worthwhile
>>> though this removes the "convenient" defaulting, requiring each target t
Hi Jeff,
subject typo: s/reuire/require/
on 2024/5/23 09:11, Jiufu Guo wrote:
> Hi,
>
> Case pr106550.c is testing constant building for 64bit
> register. So, this case requires target of has_arch_ppc64.
>
Nit: Maybe add more comments saying it fails with -m32
without having the expected
Hi Carl,
on 2024/5/23 08:29, Carl Love wrote:
> Kewen:
>
> On 5/13/24 22:44, Kewen.Lin wrote:
>>> perform the same operation as setting a specific element in the vector in
>>> C code. For example:
>>>
>>> src_v4si = __builtin_vec_set_v4si (sr
Hi,
on 2024/5/21 11:04, Alexandre Oliva wrote:
> On May 8, 2024, "Kewen.Lin" wrote:
>
>>>> How about the generic one "longdouble64"? I did a grep and found it has
>>>> one
>>>> use, I'd expect it can work here. :)
>>>
&g
Hi,
on 2024/2/26 13:43, jeevitha wrote:
> Hi All,
>
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
>
> PR110040 exposes an issue concerning moves from vector registers to GPRs.
> There are two moves, one for upper 64 bits and the other for the lower
> 64 bits.
Hi Carl,
on 2024/5/22 08:13, Carl Love wrote:
> Kewen:
>
> On 5/13/24 19:54, Kewen.Lin wrote:
>> Hi,
>>
>> on 2024/4/20 05:17, Carl Love wrote:
>>> rs6000, add overloaded vec_sel with int128 arguments
>>>
>>> Extend the vec_sel b
Hi Carl,
on 2024/5/18 04:20, Carl Love wrote:
> Kewen:
>
> I am working thru the patches. I made the changes as requested for this
> patch but have a question about
> one of your comments.
>
> On 5/14/24 00:53, Kewen.Lin wrote:
>> Hi,
>>
>> on 2024/
Hi,
on 2024/5/16 12:08, Andrew Pinski wrote:
>
> On Thu, May 16, 2024, 4:09 AM Kewen.Lin <mailto:li...@linux.ibm.com>> wrote:
>
> Hi,
>
> As the associated test case in PR114846 shows, currently
> with eh_return involved some register restoring for EH
Hi,
As the associated test case in PR114846 shows, currently
with eh_return involved some register restoring for EH
RETURN DATA in epilogue can clobber the one which holding
the return value. Referring to the existing handlings in
some other targets, this patch makes eh_return expander
call one
Hi Joseph and Richi,
Thanks for the suggestions and comments!
on 2024/5/10 14:31, Richard Biener wrote:
> On Thu, May 9, 2024 at 9:12 PM Joseph Myers wrote:
>>
>> On Wed, 8 May 2024, Kewen.Lin wrote:
>>
>>> to widen IFmode to TFmode. To make build_common_
Hi,
on 2024/4/20 05:18, Carl Love wrote:
> rs6000, remove __builtin_vsx_xvcmpeqsp_p built-in
>
> The built-in __builtin_vsx_xvcmpeqsp_p is a duplicate of the overloaded
> __builtin_altivec_vcmpeqfp_p built-in. The built-in is undocumented and
> there are no test cases for it. The patch removes
Hi,
on 2024/4/20 05:17, Carl Love wrote:
> rs6000, Remove __builtin_vsx_xvcvspsxws built-in
>
> The built-in __builtin_vsx_xvcvspsxws is a duplicate of the vec_signed
> built-in that is documented in the PVIPR. The __builtin_vsx_xvcvspsxws
> built-in is not documented and there are no test
Hi,
on 2024/4/20 05:17, Carl Love wrote:
> rs6000, extend the current vec_{un,}signed{e,o} built-ins
>
> The built-ins __builtin_vsx_xvcvspsxds and __builtin_vsx_xvcvspuxds
> convert a vector of floats to signed/unsigned long long ints. Extend the
> existing vec_{un,}signed{e,o} built-ins to
Hi,
on 2024/4/20 05:17, Carl Love wrote:
> rs6000, fix error in unsigned vector float to unsigned int built-in
> definitions
>
> The built-ins __builtin_vsx_vunsigned_v2df and__builtin_vsx_vunsigned_v4sf
> are supposed to take a vector of floats and return a vector of unsigned
> long long
Hi,
on 2024/4/20 05:18, Carl Love wrote:
> rs6000, remove vector set and vector init built-ins.
>
> The vector init built-ins:
>
> __builtin_vec_init_v16qi, __builtin_vec_init_v8hi,
> __builtin_vec_init_v4si, __builtin_vec_init_v4sf,
> __builtin_vec_init_v2di, __builtin_vec_init_v2df,
>
Hi,
on 2024/4/20 05:18, Carl Love wrote:
> rs6000, remove __builtin_vsx_xvcmpeqsp built-in
>
> The built-in __builtin_vsx_xvcmpeqsp is a duplicate of the overloaded
> vec_cmpeq built-in. The built-in is undocumented. The built-in and
> the test cases are removed.
>
> gcc/ChangeLog:
> *
Hi,
on 2024/4/20 05:18, Carl Love wrote:
> rs6000, extend vec_xxpermdi built-in for __int128 args
>
> Add a new overloaded instance for vec_xxpermdi
>
>__int128 vec_xxpermdi (__int128, __int128, const int);
>
> Update the documentation to include a reference to the new built-in
> instance.
Hi,
on 2024/5/14 11:00, Jiufu Guo wrote:
> Hi,
>
> Thanks a lot for your helpful review!
>
> "Kewen.Lin" writes:
>
>> Hi,
>>
>> on 2024/5/13 10:57, Jiufu Guo wrote:
>>> Hi,
>>>
>>> For PR96866, when gcc print asm code f
Hi,
on 2024/4/20 05:18, Carl Love wrote:
> rs6000, remove __builtin_vsx_xvnegdp and __builtin_vsx_xvnegsp built-ins
>
> The undocumented __builtin_vsx_xvnegdp and __builtin_vsx_xvnegsp are
> redundant. The overloaded vec_neg built-in provides the same
> functionality. The two buit-ins are not
Hi,
on 2024/4/20 05:18, Carl Love wrote:
> rs6000, remove __builtin_vsx_vperm_* built-ins
>
> The undocumented built-ins:
> __builtin_vsx_vperm_16qi_uns,
> __builtin_vsx_vperm_1ti,
> __builtin_vsx_vperm_1ti_uns,
> __builtin_vsx_vperm_2df,
> __builtin_vsx_vperm_2di,
>
Hi,
on 2024/4/20 05:18, Carl Love wrote:
> rs6000, remove the vec_xxsel built-ins, they are duplicates
>
> The following undocumented built-ins are covered by the existing overloaded
> vec_sel built-in definitions.
>
> const vsc __builtin_vsx_xxsel_16qi (vsc, vsc, vsc);
> same as vsc
Hi,
on 2024/4/20 05:17, Carl Love wrote:
> rs6000, add overloaded vec_sel with int128 arguments
>
> Extend the vec_sel built-in to take three signed/unsigned int128 arguments
> and return a signed/unsigned int128 result.
>
> Extending the vec_sel built-in makes the existing buit-ins
>
Hi,
on 2024/4/20 05:17, Carl Love wrote:
> rs6000, remove duplicated built-ins of vecmergl and vec_mergeh
>
> The following undocumented built-ins are same as existing documented
> overloaded builtins.
>
> const vf __builtin_vsx_xxmrghw (vf, vf);
> same as vf __builtin_vec_mergeh (vf, vf);
Hi,
on 2024/5/9 15:35, HAO CHEN GUI wrote:
> Hi Kewen,
> Thanks for your comments.
>
> 在 2024/5/9 13:44, Kewen.Lin 写道:
>> Hi,
>>
>> on 2024/5/8 14:47, HAO CHEN GUI wrote:
>>> Hi,
>>> This patch enables overlapped by-piece operations. On r
Hi,
on 2024/5/13 10:57, Jiufu Guo wrote:
> Hi,
>
> For PR96866, when gcc print asm code for modifier "%a" which requires
> an address operand, while the operand is with the constraint "X" which
> allow non-address form. An error message would be reported to indicate
> the invalid asm operands.
Hi,
on 2024/4/20 05:16, Carl Love wrote:
>
> rs6000, Remove __builtin_vsx_cmple* builtins
>
> The built-ins __builtin_vsx_cmple_u16qi, __builtin_vsx_cmple_u2di,
> __builtin_vsx_cmple_u4si and __builtin_vsx_cmple_u8hi should take
> unsigned arguments and return an unsigned result. The current
on 2024/5/10 17:29, HAO CHEN GUI wrote:
> Hi,
> This patch enables overlapped by-piece operations. On rs6000, default
> move/set/clear ratio is 2. So the overlap is only enabled with compare
> by-pieces.
>
> Compared to previous version, the change is to remove power8
> requirement from test
Hi,
on 2024/5/8 14:47, HAO CHEN GUI wrote:
> Hi,
> This patch enables overlapped by-piece operations. On rs6000, default
> move/set/clear ratio is 2. So the overlap is only enabled with compare
> by-pieces.
Thanks for enabling this, did you evaluate if it can help some benchmark?
>
>
Hi,
on 2024/5/9 06:01, Steve Kargl wrote:
> On Wed, May 08, 2024 at 01:27:53PM +0800, Kewen.Lin wrote:
>>
>> Previously effective target fortran_real_c_float128 never
>> passes on Power regardless of the default 128 long double
>> is ibmlongdouble or ieeelongdouble.
on 2024/4/30 07:11, Alexandre Oliva wrote:
> On Apr 29, 2024, "Kewen.Lin" wrote:
>
>> Thanks for catching this and sorry
>> that I didn't check it before suggesting it, I think we can aggressively
>> drop this effective target instead to avoid any possibl
Hi Richi,
>> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
>> index c584664e168..58e48f7dc55 100644
>> --- a/gcc/doc/invoke.texi
>> +++ b/gcc/doc/invoke.texi
>> @@ -18363,11 +18363,11 @@ If @code{N=0}, no pad location is recorded.
>> The NOP instructions are inserted at---and maybe
Hi,
Since r9-4728 the powerpcspe support had been removed, this
follow-up patch is to remove the remaining pieces in testsuite.
Regtested on powerpc64-linux-gnu P8/P9 and
powerpc64le-linux-gnu P9 and P10.
I'm going to push this soon if no objections.
BR,
Kewen
-
gcc/testsuite/ChangeLog:
Hi,
There are three uses of effective target powerpc_popcntb_ok,
they are all for compiling, but powerpc_popcntb_ok checks
for executable generation, which is too heavy. This patch
is to remove powerpc_popcntb_ok and adjust its three uses
accordingly.
Regtested on powerpc64-linux-gnu P8/P9 and
Hi,
As noted in PR114842, most of the test cases which require
effective target check powerpc_vsx_ok actually care about
if VSX feature is enabled, and they should adopt effective
target powerpc_vsx instead. By considering we already have
a number of test cases having explicit -mvsx in
Hi,
With the introduction of -mdejagnu-cpu=, when the test case
is specifying -mdejagnu-cpu=405, it would override the other
possibly given -mcpu=, so it would compile for PowerPC 405
for sure. This patch is to remove the effective target
powerpc_405_nocache and update all its uses.
Regtested
Hi,
Since r9-4728 the powerpcspe support had been removed, this
follow-up patch is to remove the remaining pieces in libgcc.
Bootstrapped and regtested on powerpc64-linux-gnu P8/P9 and
powerpc64le-linux-gnu P9 and P10.
I'm going to push this soon if no objections.
BR,
Kewen
-
Hi,
In function rs6000_option_override_internal, we have the
checks and adjustments like:
if (TARGET_P8_VECTOR && !TARGET_ALTIVEC)
rs6000_isa_flags &= ~OPTION_MASK_P8_VECTOR;
if (TARGET_P8_VECTOR && !TARGET_VSX)
rs6000_isa_flags &= ~OPTION_MASK_P8_VECTOR;
But in fact some previous
Hi,
Since r9-115-g559289370f76bf the support of paired single
had been dropped, but we still have some test checks and
cases for that, this patch is to get rid of them.
Regtested on powerpc64-linux-gnu P8/P9 and
powerpc64le-linux-gnu P9 and P10.
I'm going to push this soon if no objections.
Hi,
Since r12-75-g0745b6fa66c69c aix6 support had been dropped,
so we don't need to check for aix[456].* when testing, this
patch is to remove such checks.
Regtested on powerpc64-linux-gnu P8/P9 and
powerpc64le-linux-gnu P9 and P10.
I'm going to push this soon if no objections.
BR,
Kewen
-
Hi,
When making some clean up patches, I happened to find test
cases vector-{1,2}.c are having typo "powerpc64--*-*" in
target selector, which should be powerpc64-*-*. The reason
why we didn't catch before is that all our testing machines
support VMX insns, so it passes always. But it would
Hi,
When I was working on a patch to get rid of TFmode, I
noticed that define_expands vector_load_ and
vector_store_ are useless. This patch is to clean up
both.
Bootstrapped and regtested on powerpc64-linux-gnu P8/P9 and
powerpc64le-linux-gnu P9 and P10.
I'm going to push this soon if no
Hi,
When I was working on a trial patch to get rid of TFmode,
I noticed that mode attribute rreg only gets used for mode
iterator SFDF, it means that only SF and DF key-value pairs
are useful, the other are useless, so this patch is to clean
up them.
Bootstrapped and regtested on
Hi,
As shown, three uses of operands[3] are totally useless, so
this patch is to remove them to avoid any confusion.
Bootstrapped and regtested on powerpc64-linux-gnu P8/P9 and
powerpc64le-linux-gnu P9 and P10.
I'm going to push this soon if no objections.
BR,
Kewen
-
gcc/ChangeLog:
Hi,
Commit r6-2116-g2c83faf86827bf did some clean up on TFmode
and TFmode check with FLOAT128_2REG_P, but it missed to
update an assertion, this patch is to make it align.
btw, it's noticed when I'm making a patch to get rid of
TFmode.
Bootstrapped and regtested on powerpc64-linux-gnu P8/P9 and
Hi,
As PR114402 shows, we supports IEEE128 format long double
even if there is no vsx support, but there is an ICE about
cbranch as the test case shows. For now, we only supports
compare:CCFP pattern for IEEE128 fp if TARGET_FLOAT128_HW,
so in function rs6000_generate_compare we have a check
Hi,
As the discussion in PR112980, although the current
implementation for -fpatchable-function-entry* conforms
with the documentation (making N NOPs be consecutive),
it's inefficient for both kernel and userspace livepatching
(see comments in PR for the details).
So this patch is to change the
Hi,
The fix for PR112993 makes KFmode have 128 bit mode precision,
we don't need this workaround to fix up the type precision any
more, and just go with mode precision. So this patch is to
remove KFmode workaround.
Bootstrapped and regress-tested on:
- powerpc64-linux-gnu P8/P9 (with ibm128
Hi,
This reverts commit r14-6478-gfda8e2f8292a90 "range:
Workaround different type precision between _Float128 and
long double [PR112788]" as the fixes for PR112993 make
all 128 bits scalar floating point have the same 128 bit
precision, this workaround isn't needed any more.
Bootstrapped and
Hi,
Previously effective target fortran_real_c_float128 never
passes on Power regardless of the default 128 long double
is ibmlongdouble or ieeelongdouble. It's due to that TF
mode is always used for kind 16 real, which has precision
127, while the node float128_type_node for c_float128 has
128
Hi,
On rs6000, there are three 128 bit scalar floating point
modes TFmode, IFmode and KFmode. With some historical
reasons, we defines them with different mode precisions,
that is KFmode 126, TFmode 127 and IFmode 128. But in
fact all of them should have the same mode precision 128,
this
on 2024/4/29 15:20, Alexandre Oliva wrote:
> On Apr 28, 2024, "Kewen.Lin" wrote:
>
>> OK, from this perspective IMHO it seems more clear to adopt xfail
>> with effective target long_double_64bit?
>
> That's effective target is quite broken, alas. I do
on 2024/4/29 14:28, Alexandre Oliva wrote:
> On Apr 28, 2024, "Kewen.Lin" wrote:
>
>> Nit: Maybe add a prefix "testsuite: ".
>
> ACK
>
>>>
>>> From: Kewen Lin
>
>> Thanks, you can just drop this. :)
>
> I'
Hi,
on 2024/4/28 16:20, Alexandre Oliva wrote:
> On Apr 23, 2024, "Kewen.Lin" wrote:
>
>> This patch seemed to miss to CC gcc-patches list. :)
>
> Oops, sorry, thanks for catching that.
>
> Here it is. FTR, you've already responded suggesting an apparent
&g
Hi,
on 2024/4/28 16:14, Alexandre Oliva wrote:
> On Apr 24, 2024, "Kewen.Lin" wrote:
>
>> For !has_arch_pwr7 case, it still adopts peeling but as the comment (one
>> line above)
>> shows the original intention of this case is to expect not profitable for
Hi,
on 2024/4/22 17:28, Alexandre Oliva wrote:
> Ping?
> https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566525.html
>
>
> This test expects vectorization at power8+ because strict alignment is
> not required for vectors. For power7, vectorization is not to take
> place because it's not
Hi,
on 2024/4/22 17:56, Alexandre Oliva wrote:
> This patch takes feedback received for 3 earlier patches, and adopts a
> simpler approach to skip the still-failing tests, that I believe to be
> in line with ppc maintainers' expressed preferences.
>
Hi,
on 2024/4/22 18:00, Alexandre Oliva wrote:
> On Mar 10, 2021, Joseph Myers wrote:
>
>> On Wed, 10 Mar 2021, Alexandre Oliva wrote:
>>> operand exception for quiet NaN. I couldn't find any evidence that
>>> the rs6000 backend ever outputs fcmpo. Therefore, I'm adding the same
>>> execution
on 2024/4/22 17:35, Alexandre Oliva wrote:
> Ping?
> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/593947.html
>
>
> vec-mul is an execution test, but it only requires a powerpc_vsx_ok
> effective target, which is enough only for compile tests. In order to
> To check for runtime and
on 2024/4/22 17:31, Alexandre Oliva wrote:
>
> From: Olivier Hainque
>
> Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu. Also tested with
> gcc-13 on ppc64-vx7r2 and ppc-vx7r2. Ok to install?
OK, thanks!
BR,
Kewen
>
> for gcc/testsuite/ChangeLog
>
> *
on 2024/4/22 17:27, Alexandre Oliva wrote:
> Ping?
> https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566524.html
>
> The loop we're supposed to try to vectorize in
> gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c is turned into a memset
> before the vectorizer runs.
>
> Various other tests
on 2024/4/22 17:23, Alexandre Oliva wrote:
>
> These ppc lp64 tests check for errors or warnings on -mno-powerpc64.
> On powerpc64-*-vxworks* we get the same errors as on most other
> covered platforms, but the tests did not mark them as expected for
> this target. On powerpc-*-vxworks*, the
Hi,
on 2024/4/18 10:01, HAO CHEN GUI wrote:
> Hi,
> This patch replace bcdadd. with bcdsub. for bcd invalid number checking.
> bcdadd on two same numbers might cause overflow which also set
> overflow/invalid bit so that we can't distinguish it's invalid or overflow.
> The bcdsub doesn't have
Hi,
Test case builtins-6-p9-runnable.c doesn't work well on BE
due to two problems:
- When applying vec_xl_len onto data_128 and data_u128
with length 8, it expects to load 128[01] from
the memory, but unfortunately assigning 128[01] to
a {vector} {u,}int128 type variable,
Hi,
on 2024/4/17 17:05, jeevitha wrote:
> Hi,
>
> On 18/03/24 7:00 am, Kewen.Lin wrote:
>
>>> The bogus vsx_splat_ code goes all the way back to GCC 8, so we
>>> should backport this fix. Segher and Ke Wen, can we get an approval
>>> to backport this t
Hi,
on 2024/4/17 13:12, HAO CHEN GUI wrote:
> Hi,
> This patch fixes loss of return statement in maxbcd of bcd-4.c. Without
> return statement, it returns an invalid bcd number and make the test
> noneffective. The patch also enables test to run on Power9 and Big Endian,
> as all bcd
Hi,
on 2024/4/12 06:15, Peter Bergner wrote:
> FYI: This patch is an update to Will Schmidt's patches to fix PR101865:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601825.html
> https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601823.html
>
> ...taking into
on 2024/4/10 15:11, Richard Biener wrote:
> On Wed, Apr 10, 2024 at 8:24 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> pr113359-2_*.c define a struct having unsigned long type
>> members ay and az which have 4 bytes size at -m32, while
>> the related consta
Hi,
pr113359-2_*.c define a struct having unsigned long type
members ay and az which have 4 bytes size at -m32, while
the related constants CL1 and CL2 used for equality check
are always 8 bytes, it makes compiler consider the below
69 if (a.ay != CL1)
70 __builtin_abort ();
always to
on 2024/4/9 11:20, Peter Bergner wrote:
> On 4/8/24 9:37 PM, Kewen.Lin wrote:
>> on 2024/4/8 21:21, Peter Bergner wrote:
>> I prefer to remove it completely, that is:
>>
>>> -mdirect-move
>>> -Target Undocumented Mask(DIRECT_MOVE) Var(rs6000_isa_flags) War
Hi Peter,
on 2024/4/8 21:21, Peter Bergner wrote:
> On 4/8/24 3:55 AM, Kewen.Lin wrote:
>> on 2024/4/6 06:28, Peter Bergner wrote:
>>> +mno-direct-move
>>> +Target Undocumented WarnRemoved
>>> +
>>> mdirect-move
>>> -Target Undocument
on 2024/4/8 18:47, Richard Biener wrote:
> On Mon, Apr 8, 2024 at 11:23 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> As PR114614 shows, the newly added test case gcov-20.c by
>> commit r14-9789-g08a52331803f66 failed on targets which do
>> not support atomic p
on 2024/4/8 18:47, Richard Biener wrote:
> On Mon, Apr 8, 2024 at 11:22 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> As the comments in PR88309 show, there are two oversights
>> in rs6000_gimple_fold_builtin that pass align in bytes to
>> build_aligned_type but w
Hi,
As the comments in PR88309 show, there are two oversights
in rs6000_gimple_fold_builtin that pass align in bytes to
build_aligned_type but which actually requires align in
bits, it causes unexpected ICE or hanging in function
is_miss_rate_acceptable due to zero align_unit value.
This patch
Hi,
As PR114614 shows, the newly added test case gcov-20.c by
commit r14-9789-g08a52331803f66 failed on targets which do
not support atomic profile update, there would be a message
like:
warning: target does not support atomic profile update,
single mode is selected
Since the test
Hi Mike,
on 2024/3/20 12:16, Michael Meissner wrote:
> This patch adds some simple tests for -mcpu=power11 support. In order to run
> these tests, you need an assembler that supports the appropriate option for
> supporting the Power11 processor (-mpower11 under Linux or -mpwr11 under AIX).
>
>
Hi Peter,
on 2024/4/6 06:28, Peter Bergner wrote:
> This is a cleanup patch in preparation to fixing the real bug in PR101865.
> TARGET_DIRECT_MOVE is redundant with TARGET_P8_VECTOR, so alias it to that.
> Also replace all usages of OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR
> and delete
on 2024/4/3 19:18, Jakub Jelinek wrote:
> On Wed, Apr 03, 2024 at 07:01:50PM +0800, Kewen.Lin wrote:
>> Thanks for the details on debugging support, but IIUC with this workaround
>> being adopted, the debuggability on hidden args are already broken, aren't?
>
> No.
> In
Hi!
on 2024/4/3 17:23, Jakub Jelinek wrote:
> On Wed, Apr 03, 2024 at 05:02:40PM +0800, Kewen.Lin wrote:
>> on 2024/4/3 16:35, Jakub Jelinek wrote:
>>> On Wed, Apr 03, 2024 at 01:18:54PM +0800, Kewen.Lin wrote:
>>>>> I'd prefer not to remove DECL_ARGUMENTS
Hi Jakub,
on 2024/4/3 16:35, Jakub Jelinek wrote:
> On Wed, Apr 03, 2024 at 01:18:54PM +0800, Kewen.Lin wrote:
>>> I'd prefer not to remove DECL_ARGUMENTS chains, they are valid arguments
>>> that just some
>>> invalid code doesn't pass. By removing th
Hi Jakub,
on 2024/4/2 16:03, Jakub Jelinek wrote:
> On Tue, Apr 02, 2024 at 02:12:04PM +0800, Kewen.Lin wrote:
>>>>>> The old code for the unused hidden parameter (which was the 9th param)
>>>>>> would
>>>>>> fall thru to
Hi!
on 2024/3/24 02:37, Ajit Agarwal wrote:
>
>
> On 23/03/24 9:33 pm, Peter Bergner wrote:
>> On 3/23/24 4:33 AM, Ajit Agarwal wrote:
> - else if (align_words < GP_ARG_NUM_REG)
> + else if (align_words < GP_ARG_NUM_REG
> +|| (cum->hidden_string_length
> +
Hi!
on 2024/3/22 17:36, Jakub Jelinek wrote:
> On Fri, Mar 22, 2024 at 02:55:43PM +0530, Ajit Agarwal wrote:
>> rs6000: Stackoverflow in optimized code on PPC [PR100799]
>>
>> When using FlexiBLAS with OpenBLAS we noticed corruption of
>> the parameters passed to OpenBLAS functions. FlexiBLAS
>>
Hi Jakub,
on 2024/3/19 01:21, Jakub Jelinek wrote:
> Hi!
>
> The c23-stdarg-8.c test (as well as the new test below added to cover even
> more cases) FAIL on powerpc64le-linux and presumably other powerpc* targets
> as well.
> Like in the r14-9503-g218d174961 change on x86-64 we need to advance
Hi,
on 2024/3/16 04:34, Peter Bergner wrote:
> On 3/6/24 3:27 AM, Kewen.Lin wrote:
>> on 2024/3/4 02:55, jeevitha wrote:
>>> The following patch has been bootstrapped and regtested on
>>> powerpc64le-linux.
>>>
Hi,
on 2024/3/8 19:33, Rene Rebe wrote:
> This might not be the best timing -short before a major release-,
> however, Sam just commented on the bug I filled years ago [1], so here
> we go:
>
> Glibc uses .machine to determine assembler optimizations to use.
> However, since reworking the rs6000
Hi,
on 2024/3/4 02:55, jeevitha wrote:
> Hi All,
>
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
>
> When we expand the __builtin_vsx_splat_2di function, we were allowing
> immediate
Hi,
on 2024/3/1 10:41, HAO CHEN GUI wrote:
> Hi,
> This patch fixes regression cases in gcc.target/powerpc/rlwimi-2.c. In
> combine pass, SImode (subreg from DImode) lshiftrt is converted to DImode
> lshiftrt with an out AND. It matches a DImode rotate and mask insert on
> rs6000.
>
> Trying 2
Hi,
on 2024/2/21 01:57, Carl Love wrote:
>
> GCC maintainers:
>
> The patch adds documentation a number of built-ins.
>
> The patch has been tested on Power 10 with no regressions.
>
> Please let me know if this patch is acceptable for mainline. Thanks.
>
> Carl
>
Hi,
on 2024/2/21 01:58, Carl Love wrote:
> GCC maintainers:
>
> The patch changes the vec-cmpne.c from a compile only test to a runnable
> test. The macros to create the functions needed to test the built-ins and
> verify the restults are all there in the include file. The .c file just
>
101 - 200 of 1510 matches
Mail list logo