I'd like to PING:
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01713.html
I've included the entire patch below, since I missed the test cases in
the original submission and Segher asked for some updated text for the
hook documentation which I've included below.
Peter
gcc/
PR target/
On 7/5/18 2:36 PM, Jeff Law wrote:
> On 07/02/2018 03:50 PM, Peter Bergner wrote:
>> I'd like to PING:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01713.html
>>
>> I've included the entire patch below, since I missed the test cases in
>>
On 10/5/19 12:20 PM, Segher Boessenkool wrote:
> On Fri, Oct 04, 2019 at 06:31:34PM -0300, Tulio Magno Quites Machado Filho
> wrote:
>> Remove all -L directories from LINK_OS_EXTRA_SPEC32 and
>> LINK_OS_EXTRA_SPEC64 so that user directories specified at
>> build time have higher preference over th
Before, LRA, we have an insn that sets a TImode pseudo with an integer
constant and a following insn that copies that TImode pseudo to a PTImode
pseudo. During LRA spilling, we generate a new insn that sets a PTImode
pseudo to that constant directly and we ICE because we do not recognize
that as a
My fix to PR92923 seems to have caused the vmx/ops.c and vsx-vector-6.p*.c
test failures. The ops.c issue is we need a new option to quiet a warning
we didn't see when we were emitting VIEW_CONVERT_EXPRs. The other test
cases just need a slight adjustment to some of their counts. However, we
wer
On 1/9/20 4:51 PM, Segher Boessenkool wrote:
> On Thu, Jan 09, 2020 at 01:44:59PM -0600, Peter Bergner wrote:
>> The other test cases just need a slight adjustment to some of their
>> counts.
>
> What were the changes? Or, I'll just trust you looked at it and it is
>
On 1/9/20 6:29 PM, Peter Bergner wrote:
> On 1/9/20 4:51 PM, Segher Boessenkool wrote:
>> Splitting out separate functions in the testcase shouldn't be so much
>> work? Or am I too optimistic :-)
>>
>> This should make the test a good deal less prone to random ch
On 2/8/20 11:13 AM, Segher Boessenkool wrote:
>> +/* { dg-final { scan-assembler-times {\mvperm[r]?\M} 1 } } */
>
> You can write this without the square brackets, fwiw.
>
> Okay for trunk. Thank you!
Ok, I pushed this change with your suggestion to remove the square brackets
on the above regex
On 12/4/19 1:16 PM, Segher Boessenkool wrote:
> For future patches: it is much easier to review if you make the big,
> mechanical move a separate (earlier) patch.
Will do.
>> I have also
>> included a small patch to disable running the powerpc/dfp/ tests even for
>> powerpc*-linux when --disab
On 12/4/19 2:47 PM, Iain Sandoe wrote:
> Peter Bergner wrote:
>>
>> Why isn't just testing check_effective_target_dfp enough to disable the
>> tests on Darwin, --disable-decimal-float, etc.?
>
> … It should be a better solution - I will confirm this.
Thanks for
On 12/4/19 2:50 PM, Segher Boessenkool wrote:
> It would be nice to keep *some* dfp test(s) to make sure we don't ICE.
> If we disabled all such tests already, like with this patch, we wouldn't
> have ICEd or seen this problem. That can be a separate test of course
> (and could be outside gcc.targ
On 12/5/19 2:44 AM, Iain Sandoe wrote:
> Segher Boessenkool wrote:
>> On Wed, Dec 04, 2019 at 03:53:30PM -0600, Peter Bergner wrote:
>>> Sure, I can add a test in gcc.target/powerpc/ that uses both a builtin
>>> and an overloaded builtin to make sure we don't ICE w
On 12/6/19 5:12 PM, Segher Boessenkool wrote:
> On Thu, Dec 05, 2019 at 08:44:57AM +, Iain Sandoe wrote:
>> .. or I can just force a false return from effective_target_dfp as we
>> do for other cases where assembler support does not imply system
>> support.
>
> That's what I would do, yes.
On 12/4/19 5:03 PM, Segher Boessenkool wrote:
> On Wed, Dec 04, 2019 at 03:53:30PM -0600, Peter Bergner wrote:
>> Right. I'll come up with a patch and hopefully Iain and David can test
>> on Darwin and AIX and I can test on Linux with --enable-decimal-float
>> and --di
On 12/10/19 12:27 PM, Peter Bergner wrote:
> Ok, how about the patch below? If Iain and David could test this on Darwin
> and AIX respectively, that would be great. I'm currently testing this on
> powerpc64le-linux, with and without --disable-decimal-float.
So my --enable-decima
PR92923 shows a problem where builtin function usage is causing performance
problems due to unneeded subreg usage. These are being caused by the front-
end emitting unneeded VIEW_CONVERT_EXPR's on the builtin functions operands.
These in tern where caused by a lack of overloaded builtin entries in
On 12/18/19 8:15 AM, Segher Boessenkool wrote:
>> +/* { dg-do compile { target { powerpc*-*-* } } } */
>> +/* { dg-options "-w -O2 -mdejagnu-cpu=power9" } */
>
> You don't need that target clause in gcc.target/powerpc (and dg-do compile
> is the default, but having it explicit is also fine of cour
On 12/20/19 9:35 AM, Segher Boessenkool wrote:
> Something automated to verify what we implement is what we have documented
> would be neat to have. Maybe this becomes feasible with the rewrite of
> the builtin stuff :-)
Agreed!
>> This passed bootstrap and regression testing with no errors.
On 12/20/19 12:20 PM, Peter Bergner wrote:
>> On what kind of system did you test?
>>
>> I'd like to see this tested on both BE and LE, and various processor
>> generations -- but we'll see if it regresses anyway, and it is still
>> stage 3. So, okay fo
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 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/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/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 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 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
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
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
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
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/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/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
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
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 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
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/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/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/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/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 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/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/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 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 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 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 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 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/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
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 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 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 8/27/23 9:06 PM, Kewen.Lin wrote:
> Assuming we only have ELFv2_ABI_CHECK in PCREL_SUPPORTED_BY_OS, we
> can have either TARGET_PCREL or !TARGET_PCREL after the checking.
> For the latter, it's fine and don't need any checks. For the former,
> if it's implicit, for !TARGET_PREFIXED we will clean
On 8/25/23 6:20 AM, Kewen.Lin wrote:
> btw, I was also expecting that we don't implicitly set
> OPTION_MASK_PCREL any more for Power10, that is to remove
> OPTION_MASK_PCREL from OTHER_POWER10_MASKS.
So my patch removes the flag from the default power10 flags, like
you want. However, it doesn't r
On 11/13/23 8:33 PM, Kewen.Lin wrote:
>> if (PCREL_SUPPORTED_BY_OS)
>
>> + else
>> +{
>> + if (TARGET_PCREL
>> + && (rs6000_isa_flags_explicit & OPTION_MASK_PCREL) != 0)
>> +error ("use of %qs is invalid for this target", "-mpcrel");
>>rs6000_isa_flags &= ~OPTION_MAS
On 11/12/23 6:08 AM, Lehua Ding wrote:
> V3 Changes:
> 1. fix three ICE.
> 2. rebase
I tested this on powerpc64le-linux and powerpc64-linux. The LE build
bootstrapped fine and it looks like only one testsuite FAIL which I have
to look into why it's FAILing.
The BE build did bootstrap, but t
On 11/13/23 11:37 PM, Lehua Ding wrote:
> On 2023/11/14 3:37, Vladimir Makarov wrote:
>> Also besides testing major targets I'd recommend testing at least one big
>> endian target (I'd recommend ppc64be. gcc110.fsfrance.org could be used
>> for this). Plenty RA issues occur because BE targets are
PCREL data accesses are only officially supported on ELFv2. We currently
incorrectly enable PCREL on all Power10 compiles in which prefix instructions
are also enabled. Rework the option override code so we only enable PCREL
for those ABIs that actually support it.
Jeevitha has confirmed this pa
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
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 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 * 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
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
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
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. */
>>
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/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 ("
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/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
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/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/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/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/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 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 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
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/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
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 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 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 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 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 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/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
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/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
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
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
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
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
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
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
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
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.
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/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;
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 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 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/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
1 - 100 of 1091 matches
Mail list logo
