On 10/3/24 2:24 PM, Segher Boessenkool wrote:
> On Thu, Mar 21, 2024 at 06:21:48PM +0530, jeevitha wrote:
>> PTImode assists in generating even/odd register pairs on 128 bits. When the
>> user
>> specifies PTImode as an attribute, it breaks because there is no internal
>> type
>> to handle this
On 8/26/24 10:39 AM, Segher Boessenkool wrote:
> On Thu, Aug 22, 2024 at 05:39:36PM +0800, Kewen.Lin wrote:
>>> - if (ALTIVEC_OR_VSX_VECTOR_MODE (mode) || mode == TImode)
>>> + if (ALTIVEC_OR_VSX_VECTOR_MODE (mode) || mode == TImode
>>> + || mode == PTImode)
>>
>> Maybe
On 8/26/24 10:45 AM, Segher Boessenkool wrote:
> On Thu, Aug 22, 2024 at 08:48:19PM -0500, Peter Bergner wrote:
>> I agree, there probably is code in the backend that currently handles TImode
>> that should probably be changed to handle both by using your new macro.
>
> That
On 8/22/24 8:48 PM, Peter Bergner wrote:
> On 8/22/24 4:39 AM, Kewen.Lin wrote:
>> OK for trunk and all active release branches with/without these nits tweaked,
>> but please give others two days or so to comment, thanks!
>
> I'll make the suggested changes and push the
On 8/22/24 4:39 AM, Kewen.Lin wrote:
> on 2024/8/21 21:14, Peter Bergner wrote:
>> - if (ALTIVEC_OR_VSX_VECTOR_MODE (mode) || mode == TImode)
>> + if (ALTIVEC_OR_VSX_VECTOR_MODE (mode) || mode == TImode
>> + || mode == PTImode)
>
> Maybe
Our power8 swap optimization pass has some special handling for optimizing
swaps of TImode variables. The test case reported in bugzilla uses a call
to __atomic_compare_exchange, which introduces a variable of PTImode and
that does not get the same treatment as TImode leading to wrong code
genera
rs6000 patches should CC the rs6000 port maintainers. I've CC'd them on
this note.
Peter
On 8/15/24 3:44 AM, Victor Do Nascimento wrote:
> Following the migration of the dot_prod optab from a direct to a
> conversion-type optab, ensure all back-end patterns incorporate the
> second machine mode
On 8/12/24 11:03 AM, Segher Boessenkool wrote:
> On Mon, Aug 12, 2024 at 10:59:01AM -0500, Peter Bergner wrote:
>> Ping * 3. [Message-ID:
>> <1e003d78-3b2e-4263-830a-7c00a3e9d...@linux.ibm.com>]
>>
>> Segher, this resolves the issues you mentioned in your revie
Ping * 3. [Message-ID: <1e003d78-3b2e-4263-830a-7c00a3e9d...@linux.ibm.com>]
Segher, this resolves the issues you mentioned in your review.
This was on the top of your patch review queue before, so maybe
we have queue overflow? ;-)
Peter
On 6/18/24 5:59 PM, Peter Bergner wrote:
>
On 8/11/24 9:42 PM, Kewen.Lin wrote:
> One difference with this change is that previously users specify -mno-vsx to
> disable all vector insns (both VMX and VSX) on Power[89], now they should
> use -mno-altivec for that purpose. I think it's better as it matches the
> behaviors on Power7?
I hope
On 8/9/24 4:43 PM, Segher Boessenkool wrote:
> On Fri, Aug 09, 2024 at 03:50:50PM -0500, Peter Bergner wrote:
>> I'm fine with the TARGET_P10_* macro, since it's more readable than saying
>> TARGET_POWER10 && TARGET_ALTIVEC && TARGET_VSX, especially when
On 8/9/24 12:02 PM, Vladimir Makarov wrote:
> I believe your should reverse the original patch and all the patches you
> submitted to fix the issues with the original patch.
I agree this commit should be reverted and Kyrill has pushed that already,
so bootstrap should be restored now. Thank you K
On 8/9/24 12:54 PM, Segher Boessenkool wrote:
>> --- a/gcc/config/rs6000/altivec.md
>> +++ b/gcc/config/rs6000/altivec.md
>> @@ -623,7 +623,7 @@ (define_insn "altivec_eqv1ti"
>>[(set (match_operand:V1TI 0 "altivec_register_operand" "=v")
>> (eq:V1TI (match_operand:V1TI 1 "altivec_register
On 8/9/24 4:50 AM, Kewen.Lin wrote:
> As PR116266 shows, we miss TARGET_P10_VECTOR to guard those
> Power10 related vector instructions as well as their
> according built-in functions. This patch is to introduce...
LGTM.
The only change I would suggest is s/according/associated/ in
the sentence
On 7/31/24 10:21 PM, Kewen.Lin wrote:
> on 2024/8/1 01:52, Carl Love wrote:
>> Yes, I noticed that the built-ins were defined as overloaded but only had
>> one definition. Did seem odd to me.
>>
>>> either is with "vector unsigned char" as argument type, but the
>>> corresponding instance
>>> p
On 7/30/24 10:17 AM, Carl Love wrote:
> I tried, I hope I got it right, with -m32t:
>
> /* { dg-do run { target power10_hw } } */
> /* { dg-do compile { target { ! power10_hw } } } */
> /* { dg-require-effective-target int128 } */
>
> This gives:
>
> # of unsupported tests 1
>
> The
On 7/29/24 5:21 AM, Kewen.Lin wrote:
> on 2024/7/27 06:37, Carl Love wrote:
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/powerpc/vec-shift-double-runnable-int128.c
>> @@ -0,0 +1,358 @@
>> +/* { dg-do run { target power10_hw } } */
>> +/* { dg-do link { target { ! power10_hw } } } */
>> +/* {
On 7/26/24 12:07 PM, Carl Love wrote:
> On 7/24/24 11:47 AM, Segher Boessenkool wrote:
> +/* { dg-do run { target { int128 } && { power10_hw } } } */
Everything power10 is int128 always.
>>> OK, so don't need the power10_hw. Changed to just int128 for the target:
>> No, the other way aro
On 7/24/24 12:03 PM, Segher Boessenkool wrote:
>> +/* { dg-options "-mdejagnu-cpu=power10 -save-temps" } */
>
> Why the -save-temps? Always document it if you want that for something,
> but never put it in the testcase if not. A leftover from development?
I can answer this one. :-). Since th
On 7/24/24 12:06 PM, Segher Boessenkool wrote:
> On Tue, Jul 23, 2024 at 04:26:43PM -0500, Peter Bergner wrote:
>> On 7/19/24 3:04 PM, Carl Love wrote:
>>> (define_insn "vsdb_"
>>> - [(set (match_operand:VI2 0 "register_operand" "=v")
>&
On 7/19/24 3:04 PM, Carl Love wrote:
> diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
> index 5af9bf920a2..2a18ee44526 100644
> --- a/gcc/config/rs6000/altivec.md
> +++ b/gcc/config/rs6000/altivec.md
> @@ -878,9 +878,9 @@ (define_int_attr SLDB_lr [(UNSPEC_SLDB "l")
> (def
On 7/19/24 12:34 PM, Michael Meissner wrote:
> On Thu, Jul 18, 2024 at 08:08:44AM -0500, Segher Boessenkool wrote:
>>> --- a/gcc/config/rs6000/ppc-auxv.h
>>> +++ b/gcc/config/rs6000/ppc-auxv.h
>>> @@ -47,9 +47,8 @@
>>> #define PPC_PLATFORM_PPC47612
>>> #define PPC_PLATFORM_POWER8
rs6000: Catch unsupported ABI errors when using -mrop-protect
[PR114759,PR115988]
2024-07-18 Peter Bergner
gcc/testsuite/
PR target/114759
PR target/115988
* gcc.target/powerpc/pr114759-3.c: Catch unsupported ABI errors.
---
gcc/testsuite/gcc.target/powerpc/pr114759-
On 7/18/24 9:14 AM, Peter Bergner wrote:
> On 7/18/24 4:14 AM, Kewen.Lin wrote:
>>> +/* { dg-final { scan-assembler {\.\mmachine power4\M} } } */
>>> +/* { dg-final { scan-assembler {\.\mmachine altivec\M} } } */
>>
>> Nit: Both \m looks useless and can be rem
On 7/18/24 8:23 AM, Segher Boessenkool wrote:
> Everything in gcc.target/powerpc is only run for target powerpc*-*-*
> anyway, so make this just
>
> /* { dg-do compile } */
>
> please. (Or nothing, it is the default after all, but you may want to
> have it explicit).
Personally, I do like seein
On 7/18/24 4:14 AM, Kewen.Lin wrote:
>> +/* { dg-final { scan-assembler {\.\mmachine power4\M} } } */
>> +/* { dg-final { scan-assembler {\.\mmachine altivec\M} } } */
>
> Nit: Both \m looks useless and can be removed.
Fine with me. Is that because the \. acts like a \m?
>> Ok for trunk and t
On 7/18/24 12:19 AM, Kewen.Lin wrote:
> I guess you meant "Remove" is expected to remove some code explicitly and
> can be misleading here, if so how about "Don't check TARGET_LONG_DOUBLE_128
> for FLOAT128_IEEE_P modes"?
Yeah, I think that is more clear. Thanks!
Peter
On 7/17/24 4:09 AM, Kewen.Lin wrote:
> * config/rs6000/rs6000.md (@extenddf2): Remove condition
> TARGET_LONG_DOUBLE_128 for FLOAT128_IEEE_P modes.
This all LGTM, except this ChangeLog fragment doesn't match the code changes
below. Rather than removing TARGET_LONG_DOUBLE_128, you've a
On 7/16/24 6:19 PM, Carl Love wrote:
> use __int128 types that are not supported on all platforms. The
> __int128 type is only supported on 64-bit platforms. Need to check that
> the platform is 64-bits and support the __int128 type. Add the int128 and
> lp64 flags to the target test.
The test
On 7/15/24 9:19 PM, Kewen.Lin wrote:
> on 2024/7/16 04:30, Peter Bergner wrote:
>> On 7/11/24 1:24 AM, Kewen.Lin wrote:
>>> Sorry for the confusion, I meant for most target options when we emit some
>>> error
>>> message meanwhile we also unset it,
On 7/15/24 5:43 PM, Carl Love wrote:
> -/* { dg-do run } */
> +/* { dg-do run { target { lp64 } && { int128 } } } */
Why isn't this just:
/* { dg-do run { target int128 } } */
??? The int128 test should disable this on 32-bit systems just fine.
Peter
h the ROP hash insns, but we throw an error for unsupported ABIs.
This patch treats unsupported CPUs and ABIs similarly by throwing an error
both both. This matches clang behavior and allows us to simplify our tests
in the code that generates our prologue and epilogue code.
2024-07-15 Peter Bergne
On 7/11/24 1:24 AM, Kewen.Lin wrote:
> Sorry for the confusion, I meant for most target options when we emit some
> error
> message meanwhile we also unset it, such as:
>
> if (TARGET_CRYPTO && !TARGET_ALTIVEC)
> {
> if (rs6000_isa_flags_explicit & OPTION_MASK_CRYPTO)
> error ("
ons.
Ok for trunk and the release branches after some trunk burn-in time?
Peter
2024-07-12 René Rebe
Peter Bergner
gcc/
PR target/97367
* config/rs6000/rs6000.c (rs6000_machine_from_flags): Do not consider
OPTION_MASK_ALTIVEC.
(emit_asm_machine): For
On 7/10/24 1:01 AM, Kewen.Lin wrote:
>> + if (rs6000_rop_protect)
>> +{
>> + /* Disallow CPU targets we don't support. */
>> + if (!TARGET_POWER8)
>> +error ("%<-mrop-protect%> requires %<-mcpu=power8%> or later");
>> +
>> + /* Disallow ABI targets we don't support. */
>>
case for unsupported ABIs, since I'll be
working on adding ROP support for powerpc-linux and powerpc64-linux next.
Peter
2024-06-26 Peter Bergner
gcc/
PR target/114759
* config/rs6000/rs6000.cc (rs6000_override_options_after_change):
Disallow CPUs and ABIs t
Ping * 3. [Message-ID: <1e003d78-3b2e-4263-830a-7c00a3e9d...@linux.ibm.com>]
Segher, this resolves the issues you mentioned in your review.
Peter
On 6/18/24 5:59 PM, Peter Bergner wrote:
> Updated patch. This passed bootstrap and regtesting on powerpc64le-linux
> with no regr
Ping * 2. [Message-ID: <1e003d78-3b2e-4263-830a-7c00a3e9d...@linux.ibm.com>]
Segher, this resolves the issues you mentioned in your review.
Peter
On 6/18/24 5:59 PM, Peter Bergner wrote:
> Updated patch. This passed bootstrap and regtesting on powerpc64le-linux
> with no regr
On 7/3/24 4:01 AM, Kewen.Lin wrote:
>> - if (TARGET_POWER10
>> + if (TARGET_POWER8
>>&& info->calls_p
>>&& DEFAULT_ABI == ABI_ELFv2
>>&& rs6000_rop_protect)
>
> Nit: I noticed that this is the only place to change
> info->rop_hash_size to non-zero, and ...
>
>> @@ -3277,
Ping.[Message-ID: <1a420e3e-3285-4e0b-87bd-6714fedc0...@linux.ibm.com>]
Peter
On 6/19/24 4:14 PM, Peter Bergner wrote:
> We currently only emit the ROP-protect hash* insns for Power10, where the
> insns were added to the architecture. We want to emit them for earlier
> c
Ping. [Message-ID: <1e003d78-3b2e-4263-830a-7c00a3e9d...@linux.ibm.com>]
Peter
On 6/18/24 5:59 PM, Peter Bergner wrote:
> Updated patch. This passed bootstrap and regtesting on powerpc64le-linux
> with no regressions. Ok for trunk?
>
> Changes from v1:
> 1. M
?
Peter
2024-06-19 Peter Bergner
gcc/
PR target/114759
* config/rs6000/rs6000-logue.cc (rs6000_stack_info): Use TARGET_POWER8.
(rs6000_emit_prologue): Likewise.
* config/rs6000/rs6000.md (hashchk): Likewise.
(hashst): Likewise.
Fix whites
why rop_ok is needed.
Peter
rs6000: ROP - Do not disable shrink-wrapping for leaf functions [PR114759]
Only disable shrink-wrapping when using -mrop-protect when we know we
will be emitting the ROP-protect hash instructions (ie, non-leaf functions).
2024-06-17 Peter Bergner
gcc/
PR
On 6/18/24 3:38 PM, Segher Boessenkool wrote:
> From my viewpoint, -mrop-protect should not change code generation at
> all, except of course it has to emit some hash* insns :-)
Ideally, I agree with that. That said, the hash* insns only accept negative
offsets and the allowed range is rather lim
On 6/12/24 2:50 AM, Kewen.Lin wrote:
> As the recent PR115355 shows, this issue can also affect the
> behavior when users are adopting vectorization optimization,
> IMHO we should get this landed as soon as possible.
I agree we want this fixed ASAP.
> As all said above, I believe this patch is
On 6/18/24 8:20 AM, Segher Boessenkool wrote:
> On Mon, Jun 17, 2024 at 08:54:46PM -0500, Peter Bergner wrote:
>> So we should be able to shrink-wrap in the presence of the ROP protection.
[snip]
> But do we want to? And, how far, in what cases not?
My answer to the above would be &q
On 6/17/24 7:57 PM, Segher Boessenkool wrote:
> On Mon, Jun 17, 2024 at 06:49:18PM -0500, Peter Bergner wrote:
>> On 6/17/24 6:11 PM, Segher Boessenkool wrote:
>> Yeah, I didn't write that, I only moved it, but I can try to come up with
>> an explanation of why we nee
protect when we know we
will be emitting the ROP instructions (ie, non-leaf functions).
2024-06-17 Peter Bergner
gcc/
PR target/114759
* config/rs6000/rs6000.cc (rs6000_override_options_after_change): Move
the disabling of shrink-wrapping from here
*
On 6/17/24 6:11 PM, Segher Boessenkool wrote:
> "ROP insns" are the instructions used in such exploits, not what you
> mean here :-)
>
> The instructions are called "hash*"C, so maybe call tbem "hash insns"
> or "ROP protect hash insns"?.
Ok, that bad verbiage was in the extra commentary not part
On 6/16/24 9:40 PM, Kewen.Lin wrote:
> on 2024/6/17 10:31, Peter Bergner wrote:
>> On 6/16/24 9:10 PM, Kewen.Lin wrote:
>>> on 2024/6/15 01:05, Peter Bergner wrote:
>>>> That said, the --with-cpu=power5 build without fortran did bootstrap and
>>>> regtest
On 6/16/24 9:10 PM, Kewen.Lin wrote:
> on 2024/6/15 01:05, Peter Bergner wrote:
>> That said, the --with-cpu=power5 build without fortran did bootstrap and
>> regtest with no regressions, so the build did test that code path and
>> exposed no problems.
>
> OK, nice! T
On 6/14/24 1:37 PM, Carl Love wrote:
> Per the additional feedback after patch:
>
> commit c892525813c94b018464d5a4edc17f79186606b7
> Author: Carl Love
> Date: Tue Jun 11 14:01:16 2024 -0400
>
> rs6000, altivec-2-runnable.c should be a runnable test
>
> The test case ha
On 6/13/24 10:26 PM, Peter Bergner wrote:
> On 6/13/24 9:26 PM, Kewen.Lin wrote:
>>>> I understand this is just copied from the if arm, but if I read this
>>>> right, it can be
>>>> simplified as:
>>>
>>> Ok, I'll retest with that
On 6/13/24 9:34 PM, Kewen.Lin wrote:
> on 2024/6/14 05:16, Carl Love wrote:
>> /* { dg-options "-mvsx" } */
>> /* { dg-additional-options "-mdejagnu-cpu=power8" { target { !
>> has_arch_pwr8 } } } */
With the above, we're going to compile and run this test case with -mcpu=power8
or higher, whi
On 6/13/24 9:26 PM, Kewen.Lin wrote:
> on 2024/6/13 21:24, Peter Bergner wrote:
>> On 6/13/24 12:35 AM, Kewen.Lin wrote:
>>>> @@ -826,7 +826,14 @@ rs6000_stack_info (void)
>>>> info->ehrd_offset -= info->rop_hash_size;
>>>>
On 6/13/24 12:35 AM, Kewen.Lin wrote:
>> @@ -826,7 +826,14 @@ rs6000_stack_info (void)
>>info->ehrd_offset -= info->rop_hash_size;
>> }
>>else
>> -info->ehrd_offset = info->gp_save_offset - ehrd_size;
>> +{
>> + info->ehrd_offset = info->gp_save_offset - ehrd_size;
Ping.
On 6/7/24 11:06 PM, Peter Bergner wrote:
> We currently only compute the offset for the ROP hash save location in
> the stack frame for Altivec compiles. For non-Altivec compiles when we
> emit ROP mitigation instructions, we use a default offset of zero which
> corres
On 6/12/24 3:00 PM, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Jun 12, 2024 at 02:49:40PM -0500, Peter Bergner wrote:
>> testsuite: Fix pr66144-3.c test to accept multiple equivalent insns.
>> [PR115262]
>
> ("rs6000:", not "testsuite")
Done.
d get depending
on the options used.
I've verified this test case PASSes on all scenarios where the three possible
instructions are generated. Ok for trunk?
Peter
2024-06-12 Peter Bergner
gcc/testsuite/
PR testsuite/115262
* gcc.target/powerpc/pr66144-3.c: Add -fno-unrol
We currently only compute the offset for the ROP hash save location in
the stack frame for Altivec compiles. For non-Altivec compiles when we
emit ROP mitigation instructions, we use a default offset of zero which
corresponds to the backchain save location which will get clobbered on
any call. Th
I consider this one obvious, so I plan on pushing this soonish.
Peter
The ELFv2 stack frame layout comment in rs6000-logue.cc shows the ROP
hash save slot in the wrong location. Update the comment to show the
correct ROP hash save location in the frame.
gcc/
* config/rs6000/rs6000-logu
On 5/19/24 10:28 PM, HAO CHEN GUI wrote:
> +(define_expand "isinf2"
> + [(use (match_operand:SI 0 "gpc_reg_operand"))
> + (use (match_operand:SFDF 1 "gpc_reg_operand"))]
> + "TARGET_HARD_FLOAT && TARGET_P9_VECTOR"
> +{
> + emit_insn (gen_xststdcp (operands[0], operands[1], GEN_INT (0x30)));
>
On 5/21/24 8:27 AM, jeevitha wrote:
> The following patch has been bootstrapped and regtested with default
> configuration
> [--enable-checking=yes] and with --enable-checking=release on
> powerpc64le-linux.
>
> This patch removes passing the -many assembler option for release builds. Now,
> GCC
On 4/12/24 3:36 PM, Peter Bergner wrote:
> Testing was clean on both LE and BE, so I pushed the changes.
> I'll let things bake on trunk for a bit before pushing the backports.
The backports all tested clean, so I pushed them. Fixed everywhere.
Thanks everyone!
Peter
On 4/11/24 11:23 PM, Peter Bergner wrote:
> I'll make the changes above, modulo leaving the option name unchanged until
> we hear from Segher on that and report back on the LE and BE testing.
I made all of the requested changes and went with -mpower8-internal since
Segher was fin
On 4/11/24 10:31 PM, Kewen.Lin wrote:
>> The passed bootstrap and regtest on powerpc64le-linux. Ok for trunk?
>
> Thanks for fixing this. I guess it should go well on powerpc64-linux too,
> but since it's very late stage4 now, could you also test this on BE machine?
Will do, after making the ch
so ok for backports after
some burn-in time on trunk?
Peter
2024-04-11 Will Schmidt
Peter Bergner
gcc/
PR target/101865
* config/rs6000/rs6000-builtin.cc (rs6000_builtin_is_supported): Use
TARGET_POWER8.
* config/rs6000/rs6000
On 4/9/24 3:19 PM, Peter Bergner wrote:
> Ok, current trunk ignores -mno-direct-move and warns on -mdirect-move, so to
> keep the same behavior for GCC 14 (before removing in stage1), we want just:
>
> mdirect-move
> -Target Undocumented Mask(DIRECT_MOVE) Var(rs6000_isa_fla
On 4/9/24 12:37 AM, Kewen.Lin wrote:
> Since removing it completely is a stage1 thing, I prefer to keep mdirect-move
> and -mno-direct-move handlings as before, WarnRemoved and Ignore separately.
Ok, current trunk ignores -mno-direct-move and warns on -mdirect-move, so to
keep the same behavior fo
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) WarnRemoved
>
> The reason why you still kept it is to keep a
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 Undocumented Mask(DIRECT_MOVE) Var(rs6000_isa_flags) WarnRemoved
>> +Target Undocume
I'm picking up Will's patches for this bug. As an FYI, this is the bug where
_ARCH_PWR8 is conditional on TARGET_DIRECT_MOVE which can be disabled with
-mno-vsx which is bad.
I already posted the cleanup patch that the updated patch for this bug will rely
on, that removed the OPTION_MASK_DIRECT_M
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 the now dead mask.
This passed bootstrap and retesting on
On 4/3/24 10:45 AM, Andrew Pinski wrote:
> On Wed, Apr 3, 2024 at 8:32 AM Peter Bergner wrote:
> I think you misunderstood the patch/situtation. Most ifunc resolves
> don't use TLS at all; what is happening here is that the profiler
> (-fprofile-generate) is adding TLS usage to t
On 4/3/24 7:40 AM, H.J. Lu wrote:
> We can't profile indirect calls to IFUNC resolvers nor their callees as
> it requires TLS which hasn't been set up yet when the dynamic linker is
> resolving IFUNC symbols.
>
> Add an IFUNC resolver caller marker to cgraph_node and set it if the
> function is ca
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
>>> + && cum->actual_parm_length <= GP_ARG_NUM_REG))
>> {
>> if (TARGET_32BIT && TARGET_
On 3/22/24 5:15 AM, Ajit Agarwal wrote:
> When using FlexiBLAS with OpenBLAS we noticed corruption of
> the parameters passed to OpenBLAS functions. FlexiBLAS
> basically provides a BLAS interface where each function
> is a stub that forwards the arguments to a real BLAS lib,
> like OpenBLAS.
>
>
On 3/18/24 9:36 AM, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Feb 23, 2024 at 03:04:13PM +0530, jeevitha wrote:
>> PTImode attribute assists in generating even/odd register pairs on 128 bits.
>
> It is a mode, not an attribute. Attributes are on declarations, while
> modes are on a much more f
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.
>>
>> When we expand the __builtin_vsx_splat_2di function, we were
On 2/28/24 8:31 AM, Segher Boessenkool wrote:
> On Tue, Feb 27, 2024 at 04:50:02PM -0600, Peter Bergner wrote:
>> So it seems you're not NAKing the use of splat_input_operand, but
>> just that it needs more explanation in the git log entry, correct?
>
> I NAK the patch
On 2/27/24 6:40 AM, Segher Boessenkool wrote:
> On Tue, Feb 27, 2024 at 02:02:38AM +0530, jeevitha wrote:
>> There is no immediate value splatting instruction in Power. Currently, those
>> values need to be stored in a register or memory. To address this issue, I
>> have updated the predicate for t
On 2/26/24 7:55 PM, Kewen.Lin wrote:
> on 2024/2/26 23:07, Peter Bergner wrote:
>> so I think we should use both Jeevitha's predicate change and
>> your operands[1] change.
>
> Since either the original predicate change or operands[1] change
> can fix this issue, I
On 2/26/24 4:49 AM, Kewen.Lin wrote:
> on 2024/2/26 14:18, jeevitha wrote:
>> Hi All,
>> diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
>> index 6111cc90eb7..e5688ff972a 100644
>> --- a/gcc/config/rs6000/vsx.md
>> +++ b/gcc/config/rs6000/vsx.md
>> @@ -4660,7 +4660,7 @@
>> (define
On 2/20/24 3:27 AM, Kewen.Lin wrote:
> on 2024/2/20 02:45, Segher Boessenkool wrote:
>> On Tue, Jan 16, 2024 at 10:50:01AM +0800, Kewen.Lin wrote:
>>> it consists of some aspects:
>>> - effective target powerpc_p{8,9}vector_ok are removed
>>> and replaced with powerpc_vsx_ok.
>>
>> So all suc
On 2/20/24 3:29 AM, Kewen.Lin wrote:
> on 2024/2/20 06:35, Peter Bergner wrote:
>> rs6000: Update instruction counts due to combine changes [PR112103]
>>
>> The PR91865 combine fix changed instruction counts slightly for rlwinm-0.c.
>> Adjust expected instruction cou
rs6000: Update instruction counts due to combine changes [PR112103]
The PR91865 combine fix changed instruction counts slightly for rlwinm-0.c.
Adjust expected instruction counts accordingly.
This passed on both powerpc64le-linux and powerpc64-linux running the
testsuite in both 32-bit and 64-bit
On 1/24/24 12:04 AM, Kewen.Lin wrote:
> on 2024/1/24 11:11, Peter Bergner wrote:
>> But not with this. The -mdejagnu-cpu=power10 option already enables -mvsx.
>> If the user explcitly forces -mno-vsx via RUNTESTFLAGS, then let them.
>> The options set in RUNTESTFLAGS come aft
On 1/23/24 8:30 PM, Kewen.Lin wrote:
>> -output_operand_lossage ("invalid %%x value");
>> +output_operand_lossage ("invalid %%%c value", (code == 'S' ? 'S' :
>> 'x'));
>
> Nit: Seems simpler with
>
> output_operand_lossage ("invalid %%%c value", (char) code);
Agreed, good catch.
On 1/11/24 11:29 AM, Michael Meissner wrote:
> This is version 2 of the patch. The only difference is I made the test case
> simpler to read.
[snip]
> gcc/
>
> PR target/112886
> * config/rs6000/rs6000.cc (print_operand): Add %S output modifier.
> * doc/md.texi (Modifiers): Ment
On 1/5/24 4:18 PM, Michael Meissner wrote:
> @@ -14504,13 +14504,17 @@ print_operand (FILE *file, rtx x, int code)
> print_operand (file, x, 0);
>return;
>
> +case 'S':
> case 'x':
> - /* X is a FPR or Altivec register used in a VSX context. */
> + /* X is a FPR
On 12/14/23 9:57 PM, Peter Bergner wrote:
> On 7/16/23 10:40 PM, P Jeevitha via Gcc-patches wrote:
>> + /* For non PC-relative code, GPR2 is unavailable for register allocation.
>> */
>> + if (FIXED_R2 && !rs6000_pcrel_p ())
>> +fixed_regs[2] = 1;
[sn
On 7/16/23 10:40 PM, P Jeevitha via Gcc-patches wrote:
> Normally, GPR2 is the TOC pointer and is defined as a fixed and non-volatile
> register. However, it can be used as volatile for PCREL addressing. Therefore,
> modified r2 to be non-fixed in FIXED_REGISTERS and set it to fixed if it is
> not
On 11/24/23 3:28 AM, Kewen.Lin wrote:
>> + int regoff = INTVAL (operands[2]) * GET_MODE_SIZE (V16QImode);
>
> Is it intentional to keep GET_MODE_SIZE (V16QImode) instead of 16?
> I think if one day NUM_POLY_INT_COEFFS isn't 1 on rs6000 any more,
> we have to add one explicit .to_constant () here.
On 12/13/23 2:05 AM, Jakub Jelinek wrote:
> On Wed, Dec 13, 2023 at 08:51:16AM +0100, Richard Biener wrote:
>> On Tue, 12 Dec 2023, Peter Bergner wrote:
>>
>>> On 12/12/23 8:36 PM, Jason Merrill wrote:
>>>> This test is failing for me below C++17, I think y
On 12/12/23 8:36 PM, Jason Merrill wrote:
> This test is failing for me below C++17, I think you need
>
> // { dg-do compile { target c++17 } }
> or
> // { dg-require-effective-target c++17 }
Sorry about that. Should we do the above or should we just add
-std=c++17 to dg-options? ...or do we ne
On 12/12/23 1:26 PM, Richard Biener wrote:
>> Am 12.12.2023 um 19:51 schrieb Peter Bergner :
>>
>> On 12/12/23 12:45 PM, Peter Bergner wrote:
>>> +/* PR target/112822 */
>>
>> Oops, this should be:
>>
>> /* PR tree-optimization/112822 */
>>
On 12/12/23 12:45 PM, Peter Bergner wrote:
> +/* PR target/112822 */
Oops, this should be:
/* PR tree-optimization/112822 */
It's fixed on my end.
Peter
On 12/12/23 10:50 AM, Martin Jambor wrote:
> The testcase has reasonable size but it is specific to ppc64le and its
> altivec vectors. My plan is to ask the bug reporter to massage it into
> a target specific testcase in bugzilla. Alternatively I can try to
> craft a testcase from scratch but tha
PR109116 exposes an issue where using unspecs to access each vector component
of an opaque mode variable leads to unneeded register copies, because our rtl
optimizers cannot handle unspecs. Instead, use subregs to access each vector
component of the opaque mode variable, which our optimizers know
On 11/14/23 9:12 PM, Lehua Ding wrote:
> I've applied for machine permissions on the compile farm, can you give
> me the way to compile and run tests on PPC64BE machine? I'll take a look
> at it too, thanks a lot.
That's an old system, with too old system libgmp, etc. Let me attempt a
build there
1 - 100 of 1002 matches
Mail list logo
