; < xxlor 32,0,0
> ---
>> xxspltib 32,8
Given how we use xxlor's for vsx reg copies and how easily they
can change, I'm not sure we should even be counting them at all,
since they can change with the phase of the moon or the day of
the week.
Peter
support pcrel. Then we should modify
rs6000_pcrel_p() use PCREL_SUPPORTED_BY_OS rather than its own
semi-duplicated target/OS tests, plus any other tests for options that
might disqualify the current target/OS from supporting pcrel, when it
normally can (ie, -mmodel != medium for ELFv2).
I think then, that should allow simplifying the code in
rs6000_option_override_internal.
Thoughts?
Peter
mented.
Hopefully he'll weigh in on whether this particular patch is one of
those cases or not.
Peter
!= medium test above should probably have
some extra tests to ensure TARGET_PCREL is true (and explicit?) and
mcmodel != medium before giving an error??? Ie, a ELFv2 P10 compile
with an implicit -mpcrel and explicit -mcmodel={small,large} probably
should not error and just silently disable pcrel??? Meaning only
when we explicitly say -mpcrel -mcmodel={small,large} should we give
that error. Thoughts on that?
Peter
t the flag,
but yeah, we only have one OS that currently supports it, so maybe
not setting it makes sense? Like I said, I think I need Segher and
Mike to chime in with their thoughts.
Peter
Commit r14-3258-ge7a36e4715c716 increased the amount of folding we perform,
leading to better code. Update the expected instruction counts to match the
the number of associated vec_* built-in calls.
Tested on powerpc64le-linux with no regressions. Ok for mainline?
Peter
gcc/testsuite
. Ok for trunk if
tests are clean? Ok for GCC 10 too, after a couple of days?
Peter
gcc/
PR target/96530
* config/rs6000/rs6000.c (rs6000_invalid_conversion): Use canonical
types for type comparisons. Refactor code to simplify it.
gcc/testsuite/
PR target/96530
nts), and
> okay for 10 after letting it soak for a bit. Thanks!
Ok, I did s/element_mode/TYPE_MODE/g here and am retesting.
I'll commit it once regtesting comes back clean. Thanks!
Peter
On 8/7/20 8:59 PM, Peter Bergner wrote:
> On 8/7/20 6:52 PM, Segher Boessenkool wrote:
>> Okay for trunk if that is true (or with the necessary adjustments), and
>> okay for 10 after letting it soak for a bit. Thanks!
>
> Ok, I did s/element_mode/TYPE_MODE/g here and am ret
On 8/6/20 10:29 AM, Peter Bergner wrote:
> On 8/5/20 6:06 PM, Segher Boessenkool wrote:
> Ok, updated patch pushed to trunk. I'll push to GCC10 after a day or two.
And now pushed to GCC 10.
Peter
? Ok for GCC 10 after some bake in?
Peter
gcc/
PR target/96506
* config/rs6000/rs6000-call.c (rs6000_promote_function_mode):
(rs6000_function_arg):
gcc/testsuite/
PR target/96506
* gcc.target/powerpc/pr96506.c: New test.
diff --git a/gcc/config/rs6000
On 8/9/20 10:03 PM, Peter Bergner wrote:
> gcc/
> PR target/96506
> * config/rs6000/rs6000-call.c (rs6000_promote_function_mode):
> (rs6000_function_arg):
Oops, missed the ChangeLog entries:
gcc/
PR target/96506
* config/rs6000/r
On 8/8/20 11:59 AM, Peter Bergner wrote:
> Testing was clean, so I pushed this to trunk. Will wait before
> backporting. Thanks!
Scanning through Bill Seurer's testsuite runs for POWER, I see no fallout,
so I have pushed this to the GCC 10 branch.
Peter
On 7/23/20 3:29 PM, Jeff Law wrote:
>>> What's driving this change?
>>
>> Peter noticed IRA allocates stuff to volatile registers while it is life
>> through a call, and then LRA has to correct that, not optimal.
> I can't recall if IRA or LRA handles the ne
On 8/9/20 10:03 PM, Peter Bergner wrote:
> PR96506 shows a problem where we ICE on illegal usage, namely using MMA
> types for function arguments and return values. The solution is to flag
> these illegal usages as errors early, before we ICE.
>
> The patch below is currently bo
I was looking through some POWER10 test cases and noticed that we used
-mcpu=power10 rather than the preferred -mdejagnu-cpu=power10. I went
looking for more tests that were not converted over and came up with the
following patch. Ok for trunk?
Peter
gcc/testsuite/
* g++.dg/ext/spe1.C
re-effective-target power10_ok.
Now given the power10 function is so small (just a call to a p8
function), the chance we'll generate a p10 instruction is low (zero?),
so we could just keep the dg-do run as is (ie, always run), but
might that change one day?
Peter
cal variable, so how is it always zero and unused?
>> +/* { dg-options "-mdejagnu-cpu=power10 -O2 -w" } */
>
> Do you need -w or could a less heavy hammer work as well?
I could probably declare bar0(), bar1(), bar2() and bar3() and
those might go away? I didn't for some reason, but that may have
been for some earlier iteration of the test case. I'll have a
look at removing that.
Peter
On 8/11/20 9:00 PM, Segher Boessenkool wrote:
> On Sun, Aug 09, 2020 at 10:03:35PM -0500, Peter Bergner wrote:
>> +/* { dg-options "-mdejagnu-cpu=power10 -O2 -w" } */
>
> Do you need -w or could a less heavy hammer work as well?
So adding:
extern void bar0(); etc. was
for GCC 10 after some bake in?
Peter
gcc/
PR target/96506
* config/rs6000/rs6000-call.c (rs6000_promote_function_mode): Disallow
MMA types as return values.
(rs6000_function_arg): Disallow MMA types as function arguments.
gcc/testsuite/
PR ta
On 8/12/20 8:00 PM, Segher Boessenkool wrote:
> On Wed, Aug 12, 2020 at 03:32:18PM -0500, Peter Bergner wrote:
>> --- a/gcc/config/rs6000/rs6000-call.c
>> +++ b/gcc/config/rs6000/rs6000-call.c
>> @@ -6444,8 +6444,26 @@ machine_mode
>> rs6000_promote_function_mode (const
On 8/12/20 8:59 PM, Peter Bergner wrote:
> On 8/12/20 8:00 PM, Segher Boessenkool wrote:
>> On Wed, Aug 12, 2020 at 03:32:18PM -0500, Peter Bergner wrote:
> Ok, how about this comment then?
>
> @@ -6444,8 +6444,30 @@ machine_mode
> rs6000_promote_function_mode (const_tree
d there were no testsuite changes required.
If you ran the testsuite twice with the unpatched and patched
builds (as is required for patch submission) and there were no
regressions, then great. Wow, but great.
Peter
ttle to no compatibility
issue.
I just pushed the patch that does the rename to binutils today.
Ok for trunk and the GCC 10 branch after testing is clean?
Peter
gcc/
* config/rs6000/rs6000-builtin.def (BU_VSX_1): Rename xvcvbf16sp to
xvcvbf16spn.
* config/rs6000/rs6
On 8/13/20 4:27 PM, Segher Boessenkool wrote:
> Anyway, okay for trunk and backports. Thanks!
Ok, I committed this to trunk and waited a few days and then
pushed this to GCC 10 release branch too. Thanks!
Peter
On 8/18/20 1:34 PM, Segher Boessenkool wrote:
> On Tue, Aug 18, 2020 at 01:30:53PM -0500, Peter Bergner wrote:
>> The xvcvbf16sp mnemonic, which was just added in ISA 3.1 has been renamed
>> to xvcvbf16spn, to make it consistent with the other non-signaling conversion
>> instr
uiltins match the (future)
> documentation, and then, approved for trunk. Thank you!
This is also a bug in GCC 10, so this should be backported too.
Segher, is this ok for Carl to backport to GCC 10 after it has sat on
trunk for a few days?
Peter
bootstrap and regtesting on powerpc64le-linux with no regressions.
Raji has also done some runtime testing of her MMA tests using this patch
and they all showed no regressions either. Ok for trunk and GCC 10 after
a couple of days of burn in?
Peter
gcc/
PR target/96808
* con
GCC 10 after
>> a couple of days of burn in?
>
> Okay for both. Thanks!
Ok, fix pushed to trunk. I'll push to GCC 10 in a couple of days.
Thanks!
Peter
to either the
"Microsoft ABI" or the "System V ELF ABI".
Signed-off-by: Peter Jones
---
ChangeLog | 5 +
gcc/doc/extend.texi | 7 ---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index b0239316868..691d4cd619c 100644
t;li rT,-1"
followed by a "rldic rX,rT,SH,MB" instruction. The following patch
implements this idea.
This has passed bootstrap and regtesting on powerpc64le-linux with no
regressions. Testing on powerpc64-linux is still running.
Ok for trunk if the BE testing comes back clean too?
Peter
sits on trunk a day or two?
Peter
gcc/
PR target/96125
* config/rs6000/rs6000-call.c (rs6000_init_builtins): Define the MMA
specific types __vector_quad and __vector_pair, and initialize the
MMA built-ins if TARGET_EXTRA_BUILTINS is set.
(mma_init_bui
On 7/8/20 11:02 PM, Peter Bergner wrote:
> Is this ok for trunk assuming the bootstrap and regression testing
> show no regressions?
>
> This also affects GCC10, so I'd like to backport this before the release.
> Ok there too after it sits on trunk a day or two?
>
> Pet
on a wider variety of builds before backporting this to GCC10.
I'll try and do that tomorrow.
Thanks!!
Peter
On 7/9/20 4:10 PM, Peter Bergner wrote:
> I verified the updated test case passes on both LE and BE, so I've
> pushed this now. I'll let Bill Seurer's nightly testing try this
> on a wider variety of builds before backporting this to GCC10.
> I'll try and d
case.
Still ok for trunk?
Peter
gcc/
PR target/92488
* config/rs6000/dfp.md (trunctdsd2): New define_insn.
gcc/testsuite/
PR target/92488
* gcc.target/powerpc/convert-fp-128.c (bl, drsp, drdpq): Update counts.
(__dpd_trunctdsd2): Make conditional on !har
so is this worth it at all? :-)
So something like the following?
Peter
(define_insn "trunctdsd2"
[(set (match_operand:SD 0 "gpc_reg_operand" "=d")
(float_truncate:SD (match_operand:TD 1 "gpc_reg_operand" "d")))
(clobber (match_scratc
atives
like below. I'll test this and commit this if clean with the following
additional ChangeLog entry for the p9 addition. Thanks.
* config/rs6000/rs6000.md (define_attr "isa"): Add p9.
(define_attr "enabled"): Handle p9.
Peter
diff --git a/gcc/config/rs
On 7/17/20 5:07 PM, Peter Bergner wrote:
> As we discussed offline, we need the duplicated constraint alternatives
> like below. I'll test this and commit this if clean with the following
> additional ChangeLog entry for the p9 addition. Thanks.
Testing was clean, so I pus
ons. Raji verified
the runnable test case changes work with a fixed compiler.
Ok for trunk and backport to the GCC 10 branch once it reopens?
Peter
gcc/
PR target/96236
* config/rs6000/rs6000-call.c (rs6000_gimple_fold_mma_builtin): Handle
little-endian memory ordering
already, so it is fine for 10 immediately as
> well. Thanks!
Ok, pushed to trunk. I'll wait for the branch to reopen before pushing it
there too. Thanks!
Peter
asking for a backport.
Peter
gcc/
PR target/95907
* config/rs6000/rs6000.c (rs6000_option_override_internal): Add check
to require -mcpu=power10 if using -mpower10.
gcc/testsuite/
PR target/95907
* g++.target/powerpc/pr95907.C: New test.
diff --git a/gcc
On 7/24/20 6:32 AM, Segher Boessenkool wrote:
> On Thu, Jul 23, 2020 at 08:15:42PM -0500, Peter Bergner wrote:
>> + /* If the user explicitly uses -mpower10, ensure our ISA flags are
>> + compatible with it. */
>> + if (TARGET_POWER10
>> + &a
?
Peter
gcc/
PR target/96446
* gcc/config/rs6000/mma.md (*movpxi): Add xxsetaccz generation.
Disable split for zero constant source operand.
(mma_xxsetaccz): Change to define_expand. Call gen_movpxi.
gcc/testsuite/
PR target/96446
* gcc.target/powerpc
On 8/5/20 2:02 PM, Peter Bergner wrote:
> This patch fixes the ICE and is in the middle of regression testing.
> Ok for trunk if the testing comes back clean?
Testing was clean with no regressions.
Peter
for trunk, and later 10) with or without such a change. Thanks!
Ok, updated patch pushed to trunk. I'll push to GCC10 after a day or two.
Thanks!
Peter
hes above or comments?
If we go with the first patch for stage1, I'll add -fno-split-wide-types-early
to pr87507.c so it doesn't FAIL until the patch goes in.
Peter
On 3/28/20 2:22 PM, Segher Boessenkool wrote:
> On Fri, Mar 27, 2020 at 05:41:36PM -0500, Peter Bergner wrote:
>> A different (ie, safer) approach would be to just rerun lower-subreg at
>> its old location, regardless of whether we used -fsplit-wide-types-early.
>
> That is
On 3/30/20 6:26 AM, Segher Boessenkool wrote:
> On Mon, Mar 30, 2020 at 09:50:05AM +0100, Richard Sandiford wrote:
>> Peter Bergner via Gcc-patches writes:
>>> - if (HARD_REGISTER_NUM_P (rd) || HARD_REGISTER_NUM_P (rs))
>>> + if (HARD_REGISTER_NUM_P (rd))
>>&g
On 3/30/20 11:23 AM, Peter Bergner wrote:
> I kind of agree with Richard above on making it more applicable/symmetric,
> but why can't we just remove the HARD_REGISTER_NUM_P() tests altogether?
> It's not like lower-subreg is extending hard register lifetime usage than
> wh
On 3/30/20 3:50 AM, Richard Sandiford wrote:
> Peter Bergner via Gcc-patches writes:
>> * lower-subreg.c (pass_lower_subreg3::gate): Remove test for
>> flag_split_wide_types_early.
>>
>> diff --git a/gcc/lower-subreg.c b/gcc/lower-subreg.c
>> inde
On 4/1/20 1:32 PM, Richard Sandiford wrote:
> Peter Bergner writes:
>> Have we come to consensus on whether to split the options or not?
>> I think Segher is against it given we actually have 3 passes of
>> lower-subreg and -fsplit-wide-types would control the 1st and 3rd
same
code generated for the test case below, that we got before my PR93658 patch.
This passed bootstrap and regression testing on powerpc64le-linux with no
regressions. Ok for mainline?
Peter
gcc/
PR rtl-optimization/93974
* config/rs6000/rs6000.c
On 4/16/20 8:21 AM, Peter Bergner wrote:
> This passed bootstrap and regression testing on powerpc64le-linux with no
> regressions. Ok for mainline?
This also just passed bootstrap and regtesting on (BE) powerpc64-linux
running the testsuite in both 32-bit and 64-bit modes, with no regre
compile } ?
Ok, changed. I was trying to limit it to POWER and then thought that
no other OS on POWER supports P8 vector, so I added that hunk, but I
guess the dg-requires-effective-target is enough.
> Okay for trunk, however you choose to resolve those things. Thank you!
Thanks for the review. I just pushed the updated patch.
Peter
On 4/17/20 12:59 AM, Sebastian Huber wrote:
> Hello Segher,
>
> would you mind having a look at this patch.
>
His patch is here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543396.html
Peter
o make CSE add the (const: ...) whenever it creates a MEM with
a constant address.
This passed bootstrap and regtesting on powerpc64le-linux with no regressions.
Ok for trunk?
Peter
gcc/
PR rtl-optimization/94740
* cse.c (cse_process_notes):
gcc/testsuite/
PR rtl-optimization/9
urn x;
> return simplify_gen_binary (code, mode, op0, op1);
Ok, I'll try this and see whether we survive bootstrap and regtesting.
Thanks!
Peter
& op1 == XEXP (x, 1))
> return x;
> return simplify_gen_binary (code, mode, op0, op1);
Is there a reason you use simplify_replace_fn_rtx here, rather than
just using op0 = simplify_rtx (XEXP (x, 0))? Ditto for op1.
Does simplify_replace_fn_rtx do something that simplify_rtx doesn't?
Peter
) as well, which
fixes the ICE? The FOR loop which now follows this switch statement is
what used to modify the PLUS's operands without adding the (const:P ).
This is still in the middle of bootstrap and regtesting.
Peter
gcc/
PR rtl-optimization/94740
* cse.c (cse_process_
ET_RTX_CLASS (code))
+{
+case RTX_BIN_ARITH:
+case RTX_COMM_ARITH:
+ return simplify_gen_binary (code, GET_MODE (x), XEXP (x, 0), XEXP (x,
1));
+default:
+ break;
+ }
+
return x;
}
Peter
On 4/28/20 6:06 PM, Peter Bergner wrote:
> However, do you mean the change to be the following, since I don't think
> simplify_gen_binary ever returns NULL?
>
>
>validate_change (object, &XEXP (x, i),
>cse_process_notes (XEXP
that feels a bit hacky)
>
> (3) use the simplify_binary_operator thing above, since that at least
> should be safe, even if it potentially leaves similar bugs unfixed
> for other operators.
>
> Sorry for the runaround :-(
No problem. I appreciate the feedback and I agree we want to get this right.
I'll implement the above and report back. Thanks!
Peter
rly unless I actually tried to write something. :-()
No worries from me! I'm just glad to see this fixed before the release.
I'll kill off a bootstrap and regtest on powerpc64le-linux too, in addition
to your tests (arm & x86_64?). Thanks for your help with this!
Peter
rogress.
My testing is still running, but I like the patch a lot!
It's nice when a patch not only fixes a bug, but makes the code
*MUCH* simpler too. Well done!
Peter
On 4/29/20 4:15 PM, Peter Bergner wrote:
> On 4/29/20 3:28 PM, Richard Sandiford wrote:
>> (Sorry for going ahead and writing an alternative patch, since if we do
>> go for this, I guess the earlier misdirections will have wasted two days
>> of your time. But it seemed like I
onky mime type.
>> It looks reasonable reasonable to me. Re-using simplify_replace_fn_rtx seems
>> like a major simplification, which is definitely good.
>
> Great, thanks! Now pushed to master.
I pushed the test case to master too. Thank you everyone!
Peter
intainers on PPC patches.
I've CC'd both Segher and David.
Peter
>> Just a friendly ping on the following patch, hopefully sufficiently
>> straightforward and tested to be allowed onto branch master.
>>
>>
>> On Fri, Apr 17, 2020 at 04:49:47PM -0
he is watching his email, if at all. Given Tulio mentioned
the change in the first place, I think he's ok with the change.
He can beat me later if I'm wrong! :-)
Peter
distro releases defaulted to -m32.
Newer ppc64 BE distro releases now default to -m64.
Peter
it's necessary to send email to you and
confirm whether this company is your distributor or business partner in China?
Best Regards
Peter Liu Service & Operations Manager
China Registry (Head Office)
Tel: +86-02161918696
Fax: +86-02161918697
Mob: +86-13816428671
6012, Xingdi B
ed on
powerpc64le-linux with no regressions. In addition, patch1+patch2+patch3
has been bootstrapped and regtested on powerpc64-linux (BE), also without
regressions.
Peter
these modes can be assigned to as also been added.
This patch passed bootstrap and regtesting with no regressions on
powerpc64le-linux. Ok for trunk?
Peter
2020-06-15 Peter Bergner
Michael Meissner
gcc/
* config/rs6000/mma.md: New file.
* config/rs6000/rs6000-c.c
This patch adds the testsuite test cases for all of the MMA built-ins.
This patch plus patch1 and patch2 passed bootstrap and regtesting with no
regressions on both powerpc64le-linux and powerpc64-linux. Ok for trunk?
Peter
2020-06-15 Peter Bergner
gcc/testsuite/
* gcc.target
th no regressions
on both powerpc64le-linux and powerpc64-linux. Ok for trunk?
Peter
2020-06-15 Peter Bergner
gcc/
* config/rs6000/predicates.md (mma_input_operand): New predicate.
* config/rs6000/rs6000-builtin.def (BU_MMA_1, BU_MMA_V2, BU_MMA_3,
BU_MMA_5, BU_
On 6/15/20 5:43 PM, will schmidt wrote:
> On Mon, 2020-06-15 at 14:56 -0500, Peter Bergner via Gcc-patches wrote:
>> * config/rs6000/rs6000-cpus.def (OTHER_FUTURE_MASKS): Add
>> OPTION_MASK_MMA.
>> (POWERPC_MASKS): Likewise.
>
> Don't see POWERPC_MAS
this is more readable.
Will change.
> I've read through the rest of this patch. nothing else jumps out at me.
Thanks
Peter
the thing that is modified, and that you mention the exact
> name of the value added (spelled in full).
You are right, "mma" was not that thing that was modified.
Yeah, I like: (define_attr "type"): New type mma.
better too.
Peter
built-in names for
__builtin_vsx_xvcvspbf16 and __builtin_vsx_xvcvbf16sp.
Patch 3/3:
- No changes.
Peter
c64le-linux. This updated patch is bootstrapping and regtesting
on powerpc64le-linux. Ok for trunk if there are no regressions?
Peter
2020-06-18 Peter Bergner
Michael Meissner
gcc/
* config/rs6000/mma.md: New file.
* config/rs6000/rs600
tstrap and regtesting with no regressions on both
powerpc64le-linux and powerpc64-linux. This updated patch + patch1 is
bootstrapping and regtesting on powerpc64{,64}-linux. Ok for trunk if
there are no regressions?
Peter
2020-06-18 Peter Bergner
gcc/
* config/rs6000/pre
Changes since v1:
- No changes from v1.
This patch adds the testsuite test cases for all of the MMA built-ins.
This patch was tested with patch1 + patch2.
Peter
2020-06-18 Peter Bergner
gcc/testsuite/
* gcc.target/powerpc/mma-builtin-1.c: New test.
* gcc.target/powerpc
bled semicolon)
Fixed.
> So nregs is always 2? Maybe it is better to just assert that here then?
If in a VSR, yes. I think maybe we thought early on that if they were somehow
in a GPR then they'd take more regs, but I think maybe we've guarantee that
can't happen??? I can set it to 2 and add an assert and see if that exposes
anything.
>> @@ -19249,6 +19416,9 @@ rs6000_mangle_type (const_tree type)
>>if (SCALAR_FLOAT_TYPE_P (type) && FLOAT128_IEEE_P (TYPE_MODE (type)))
>> return ieee128_mangling_gcc_8_1 ? "U10__float128" : "u9__ieee128";
>>
>> + if (type == vector_pair_type_node) return "u13__vector_pair";
>> + if (type == vector_quad_type_node) return "u13__vector_quad";
>
> Line breaks?
Ok, added line breaks. I was kind of just following some of the code
before it. Of course other code there does it the other way! :-)
>> /* No data type wants to be aligned rounder than this. */
>> -#define BIGGEST_ALIGNMENT 128
>> +#define BIGGEST_ALIGNMENT ((TARGET_MMA) ? 512 : 128)
>
> No silly parens around TARGET_MMA please (macros should protect
> themselves, sure, but not try to protect other macros).
Fixed.
> Okay for trunk modulo the above. Thanks! This was much less painful
> than I feared. Well, maybe it is all in the other patches, I'll get to
> those tomorrow ;-)
Thanks!
Mike, can you answer the 2 questions for you above?
Peter
On 6/19/20 11:45 AM, Segher Boessenkool wrote:
> On Thu, Jun 18, 2020 at 03:45:17PM -0500, Peter Bergner wrote:
>> +;; Return 1 if this operand is valid for a MMA assemble accumulator insn.
>> +(define_special_predicate "mma_input_operand"
>> +
On 6/19/20 1:12 PM, Segher Boessenkool wrote:
> On Fri, Jun 19, 2020 at 11:47:35AM -0500, Peter Bergner wrote:
>>> Why are OImode and XImode handled here?
>>>
>>>> static bool
>>>> rs6000_modes_tieable_p (machine_mode mode1, machine_mode mode2)
>&g
On 6/19/20 2:33 PM, Peter Bergner wrote:
> On 6/19/20 1:12 PM, Segher Boessenkool wrote:
>> On Fri, Jun 19, 2020 at 11:47:35AM -0500, Peter Bergner wrote:
>>>> Why are OImode and XImode handled here?
>>>>
>>>>> static bool
>>>>>
On 6/19/20 11:47 AM, Peter Bergner wrote:
>>> +;; Special pattern to prevent DSE from generating an internal error if it
>>> +;; notices a structure copy that it wants to eliminate. This generates
>>> pretty
>>> +;; bad code, but at least it doesn't die.
On 6/19/20 12:06 PM, Peter Bergner wrote:
> On 6/19/20 11:45 AM, Segher Boessenkool wrote:
>>> +(define_insn_and_split "*mma_assemble_acc"
>>> + [(set (match_operand:PXI 0 "fpr_reg_operand" "=d")
>>> +
On 6/19/20 11:53 AM, Segher Boessenkool wrote:
>
> Okay for trunk. Thanks!
I committed this along with patch2, so it was pushed upstream with it.
Thanks!
Peter
On 6/18/20 3:42 PM, Peter Bergner wrote:
> POWER ISA 3.1 added new Matrix-Multiply Assist (MMA) instructions.
> The following patch set adds support for generating these instructions
> through built-in functions which are enabled with the -mmma option.
>
> The patch1 and patch1+pat
On 6/24/20 2:37 PM, Segher Boessenkool wrote:
> On Wed, Jun 24, 2020 at 02:28:00PM -0500, Peter Bergner via Gcc-patches wrote:
>> The back ports of the MMA patches/commits was straight forward and I'm
>> currently bootstrapping/regtesting the backports on both powerpc64le-li
rs6000: Add support for __builtin_cpu_is ("power10")
Add support for __builtin_cpu_is ("power10"). Also add documentation for
the recently added "arch_3_1" and "mma" __builtin_cpu_supports arguments.
This passed bootstrap and regtesting with no
On 6/25/20 6:54 PM, Segher Boessenkool wrote:
> Okay for trunk (maybe leave out the comma part). Thanks!
Ok, I pushed the patch without the ',' change. Thanks!
Peter
breg (reg_mode, dst, mode,
> - i * reg_mode_size),
> - simplify_gen_subreg (reg_mode, src, mode,
> - i * reg_mode_size)));
> + /* XO/OO are opaque so cannot use subregs. */
> + if ( mode == OOmode || mode == XOmode )
Ditto.
> + /* XO/OO are opaque so cannot use subregs. */
> + if ( mode == OOmode || mode == XOmode )
Ditto.
Peter
On 11/17/20 5:01 PM, Segher Boessenkool wrote:
> On Tue, Nov 17, 2020 at 12:41:58PM -0600, Peter Bergner wrote:
>>> +;; Return 1 if this operand is valid for an MMA disassemble insn.
>>> +(define_predicate "mma_disassemble_output_operand"
>>> + (match
_3_operand")]
Likewise as above, do we want to use the fpr_reg_operand predicate here
instead of input_operand?
> +(define_insn_and_split "*mma_disassemble_acc"
> + [(set (match_operand:V16QI 0 "mma_disassemble_output_operand" "=mwa")
> + (unspec:V16QI [(match_operand:XO 1 "input_operand" "d")
> + (match_operand 2 "const_0_to_3_operand")]
Likewise?
Peter
out.
This makes them a kind of pseudo aggregate type and we need to treat them
as such when we process the INIT initializer for variables with an
opaque type.
This passed bootstrap and regtesting on powerpc64le-linux with no regressions.
Ok for trunk?
Peter
gcc/cp/
PR c++/97947
ion and does constexpr.c properly punt on it rather than
> ICE?
We don't, since we don't support that with these specific types, but yeah,
an ICE isn't as good as an error message. We'll look into adding some.
Thanks.
Peter
On 12/2/20 2:37 PM, Jason Merrill wrote:
> But this patch is OK.
Ok, pushed to trunk. Thanks!
Peter
x.
Ok for trunk?
Since the ranger code that triggered this doesn't seem to be in GCC 10,
I assume we do not want to backport this this change?
Peter
gcc/
PR target/97360
* config/rs6000/rs6000-call.c (rs6000_init_builtins): Remove call to
build_distinct_type_co
2001 - 2100 of 2382 matches
Mail list logo
