On 8/31/22 4:22 AM, Kewen.Lin wrote:
> on 2022/8/27 11:50, Peter Bergner via Gcc-patches wrote:
>> - tree src_type = TREE_TYPE (src_ptr);
>> + tree src_type = (fncode == RS6000_BIF_DISASSEMBLE_ACC)
>> + ? build_pointer_type (
On 8/31/22 4:33 AM, Kewen.Lin wrote:
> @@ -1,7 +1,8 @@
> /* { dg-do compile { target { powerpc*-*-* } } } */
> /* { dg-skip-if "" { powerpc*-*-aix* } } */
> -/* { dg-options "-O2 -mpowerpc64" } */
> /* { dg-require-effective-target ilp32 } */
> +/* { dg-options "-O2 -mpowerpc64" } */
> +/* { dg-
On 8/31/22 4:33 AM, Kewen.Lin via Gcc-patches wrote:
> Commit r12-2266 updated the scanned assembly content from
>
> "{\mlvx\M|\mlxv\M|\mlxvd2x\M}"
>
> to
>
> "{\mp?lxv\M|\mlxv\M|\mlxvd2x\M}"
>
> for the test case pr86731-fwrapv-longlong.c unexpectedly.
>
> It's meant to update "lxv" to "p
On 8/31/22 10:24 AM, Segher Boessenkool wrote:
> Should *any* explicit command line flag ever be disabled like that?
> (Not talking about things like -m32 -m64, ...
In a general sense, I'd agree that the answer is no, but we do have
dependent options like -maltivec and -mvsx, etc., so a -mno-altiv
On 8/31/22 11:05 AM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 10:48:26AM -0500, Peter Bergner wrote:
>> Ditto for -msoft-float better disable any -maltivec and -mvsx, etc.
>
> Oh? Why should it disable -maltivec? -mvsx makes a little sense on
> one hand, but totally none on the other
On 8/31/22 8:59 AM, Peter Bergner wrote:
> On 8/31/22 4:22 AM, Kewen.Lin wrote:
>> on 2022/8/27 11:50, Peter Bergner via Gcc-patches wrote:
>>> - tree src_type = TREE_TYPE (src_ptr);
>>> + tree src_type = (fncode == RS6000_BIF_DISASSEMBLE_ACC)
>>> +
On 8/31/22 2:28 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 12:00:14PM -0500, Peter Bergner wrote:
> No. Instead, it just works!
>
> Try this:
> ===
> typedef float vf __attribute__((vector_size(16)));
> vf f(float x)
> {
> x *= 42;
> return (vf){x, x, x, x};
> }
> ===
> w
On 8/31/22 4:07 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 02:53:07PM -0500, Peter Bergner wrote:
>> Changing OS_MISSING_POWERPC64 as I mentioned would not add
>> OPTION_MASK_POWERPC64
>> to our cpu masks when -m32 is used.
>
> So you say this is where the bug is?
For linux64.h whic
On 8/31/22 3:51 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 01:53:48PM -0500, Peter Bergner wrote:
>> Question for my own education, when would you use VIEW_CONVERT_EXPR over
>> NOP_EXPR?
>
> VIEW_CONVERT_EXPR is essentially a bit_cast. Only use it when you need
> that, it is sub-opt
On 8/31/22 4:49 PM, Segher Boessenkool wrote:
> But it is incorrect as well. Instead, we should look if -mpowerpc64 is
> enabled explicitly, and not change it if so.
Sure, I agree with checking for explicit use. That said, I'll let
someone else work on this.
Peter
On 8/31/22 6:08 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 05:01:04PM -0500, Peter Bergner wrote:
>> The problem goes away if I use use -O1 or above, I drop -flto or I use
>> the code I originally posted without the ptr_vector_*_type
>>
>> The assert in gimple_canonical_types_compatibl
Changes from v1:
* Fix spelling typo in git log entry
* Fix broken test checking src_ptr's type
* Use NOP_EXPR rather than VIEW_CONVERT_EXPR
* Change order of dg-options
When we expand an MMA disassemble built-in with C++ using a pointer that
is cast to a valid MMA type, the type isn't passed down
On 8/31/22 6:45 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 06:36:40PM -0500, Peter Bergner wrote:
>> Changes from v1:
>> * Fix spelling typo in git log entry
>> * Fix broken test checking src_ptr's type
>> * Use NOP_EXPR rather than VIEW_CONVERT_EXPR
>> * Change order of dg-options
>>
On 9/1/22 3:29 AM, Kewen.Lin wrote:
>> I have no idea why ptr_vector_*_type would behave differently here than
>> build_pointer_type (vector_*_type_node). Using the build_pointer_type()
>> fixed it for me, so that's why I went with it. :-) Maybe this is a bug
>> in lto???
>
> Thanks for your tim
On 9/1/22 4:52 PM, Segher Boessenkool wrote:
> On Thu, Sep 01, 2022 at 11:24:00AM +0800, Jiufu Guo wrote:
>> As mentioned in PR106550, since pli could support 34bits immediate, we could
>> use less instructions(3insn would be ok) to build 64bits constant with pli.
>
>> For example, for constant 0x
When we cast pointers to our opaque MMA pointers, use NOP_EXPR rather
than VIEW_CONVERT_EXPR.
This passed bootstrap and regtesting on powerpc64le-linux with no regressions.
Ok for trunk?
I think this is just a cleanup and not a correctness thing, so I'm assuming a
backport isn't needed? Or maybe
On 9/2/22 11:31 AM, Segher Boessenkool wrote:
> I wouldn't worry about backports. If it does make other backports
> easier in the future, we can decide to backport this *then*.
Ok.
> (Did you also look at non-MMA VIEW_CONVERT_EXPR uses btw?)
I did. It seemed they were all related to pointers
On 9/2/22 12:23 PM, Segher Boessenkool wrote:
> On Fri, Sep 02, 2022 at 12:02:54PM -0500, Peter Bergner wrote:
>> On 9/2/22 11:31 AM, Segher Boessenkool wrote:
>>> (Did you also look at non-MMA VIEW_CONVERT_EXPR uses btw?)
>>
>> I did. It seemed they were all related to pointers to vectors and I r
On 9/9/22 8:27 AM, Kewen.Lin wrote:
> __attribute__((noipa))
> int foo(c){
> return 0;
> }
>
> int main ()
> {
> const __vector_quad c;
> int r = foo(c);
> return r;
> }
>
> Checking during LTO WPA, verify_type only gets type "const
> __vector_quad", no type "__vector_quad".
>
> btw, it
On 9/9/22 8:47 PM, Segher Boessenkool wrote:
> On Fri, Sep 09, 2022 at 07:56:42PM -0500, Peter Bergner wrote:
>> On 9/9/22 8:27 AM, Kewen.Lin wrote:
>>> btw, it needs some hacking in rs6000_function_arg to make this
>>> opaque type valid for function arg.
>>
>> We don't allow (at this time) __vecto
On 5/2/22 8:06 PM, Michael Meissner wrote:
> Ping #5:
>
> | Date: Tue, 12 Apr 2022 21:14:55 -0400
> | From: Michael Meissner
> | Subject: [PATCH, V4] Eliminate power8 fusion options, use power8 tuning, PR
> target/102059
> | Message-ID:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-April/
On 5/5/22 2:35 PM, Segher Boessenkool wrote:
> On Thu, May 05, 2022 at 01:59:05PM -0500, Peter Bergner wrote:
>> If we cannot get this in soonish, maybe we can at least get approval for
>> applying Mike's simpler patch to the release branches, specifically GCC 10?
>>
>>https://gcc.gnu.org/bugzi
On 5/5/22 4:27 PM, Segher Boessenkool wrote:
> On Thu, May 05, 2022 at 02:59:07PM -0500, Peter Bergner wrote:
>> On 5/5/22 2:35 PM, Segher Boessenkool wrote:
>>> A patch like that is pre-approved, even for trunk.
>>
>> That works for me! I will apply this directly to GCC 10 and regtest and
>> push
On 5/5/22 5:51 PM, Michael Meissner wrote:
> On Thu, May 05, 2022 at 02:35:34PM -0500, Segher Boessenkool wrote>> A patch
> like that is pre-approved, even for trunk.
>
> And as I said, logically we should do the same for p10 fusion. I.e.
>
>callee_isa &= ~(OPTION_MASK_P8_FUSION
>
On 5/5/22 4:27 PM, Segher Boessenkool wrote:
> On Thu, May 05, 2022 at 02:59:07PM -0500, Peter Bergner wrote:
>> On 5/5/22 2:35 PM, Segher Boessenkool wrote:
>>> Just an unconditional
>>>
>>> callee_isa &= ~OPTION_MASK_P8_FUSION;
>>> explicit_isa &= ~OPTION_MASK_P8_FUSION;
>>>
>>> will do, no?
This patch addresses an issue when compiling the MMA optimized DGEMM kernel
in OpenBLAS. The MMA code uses all 8 accumulators, which overlap all vs0-vs31
vector registers. Current trunk assigns one of the normal vector inputs to
one of the MMA instructions, which forces us to spill one of the acc
On 5/10/22 5:35 PM, Segher Boessenkool wrote:
> If you want to use this same message as commit message, you shouldn't
> say "this patch". Also, try not to use lines more than 72 positions
> wide (which handily is also a good maximum length for email messages,
> that way it can be quoted a few time
On 5/10/22 5:46 PM, Peter Bergner wrote:
>> Out of interest, did you try using v,?wa (so just two alternatives, not
>> four)? Or did you think it wouldresult in measurably worse code? Or
>> did you decide it is not such bad backend code size explosion after
>> all :-)
>
> I have not tried that,
On 5/10/22 5:35 PM, Segher Boessenkool wrote:
> Out of interest, did you try using v,?wa (so just two alternatives, not
> four)? Or did you think it wouldresult in measurably worse code? Or
> did you decide it is not such bad backend code size explosion after
> all :-)
So I tried using just "v,
On 5/17/22 6:41 PM, Segher Boessenkool wrote:
> On Mon, May 16, 2022 at 05:31:31PM -0500, Peter Bergner wrote:
>> (define_insn "mma_"
>> - [(set (match_operand:XO 0 "fpr_reg_operand" "=&d")
>> -(unspec:XO [(match_operand:V16QI 1 "vsx_register_operand" "wa")
>> -(match_operand:
As part of the MMA base support, we incremented BIGGEST_ALIGNMENT in
order to align the __vector_pair and __vector_quad types to 256 and 512
bits respectively. This had the unintended effect of changing the
default alignment used by __attribute__ ((__aligned__)) which causes
an ABI break because o
On 11/6/20 4:51 PM, Segher Boessenkool wrote:
> The ABI break is all GCC's faultt, but it is exposed by that glibc code,
> sure :-)
Right, and I'm thankful it was caught (fairly) early enough!
>> This passes bootstrap and regtesting on powerpc64le-linux with no
>> regressions.
>> Ok for mainlin
On 10/21/20 2:31 PM, Peter Bergner wrote:
> Ok, I'll wait a week and then do the backport and testing.
I just pushed this to the GCC 10 release branch now.
Peter
I'd like to ping the following MMA patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578288.html
Message-ID: <8393a33f-50ab-6720-0017-3f012803b...@linux.ibm.com>
Peter
Fwprop will happily optimize two xxsetaccz instructions into one xxsetaccz
by propagating the results of the f
On 9/12/21 2:26 PM, Segher Boessenkool wrote:
>> I also removed the mma_xxsetaccz define_expand and
>> define_insn_and_split and replaced it with a simple define_insn.
>
> In the future pleaase do that in a separate patch. That makes it *much*
> easier to read and review this.
Will do.
>>
On 9/13/21 7:17 PM, Segher Boessenkool wrote:
> On Mon, Sep 13, 2021 at 05:10:42PM -0500, Peter Bergner wrote:
>> It still has "a" match_operand...for operand 0. The match_operand
>> for operand 1 was what was removed. Want me to reword that as
>> "Remove source match_operand." or "Remove match_o
On 9/28/21 2:24 PM, Bill Schmidt via Gcc-patches wrote:
> Unless you are planning to do a backport, I think the proper way forward
> here is to just wait for the new builtin support to land. In the new code,
> we initialize all built-ins up front, and check properly at expansion time
> whether the
Sorry for taking so long to get back to this.
On 10/29/21 4:45 PM, Segher Boessenkool wrote:
> On Wed, Oct 27, 2021 at 10:17:39PM -0500, Peter Bergner wrote:
>> +/* Ensure hashst comes after mflr and hashchk comes after ld 0,16(1). */
>> +/* { dg-final { scan-assembler "mflr 0.*hashst 0," } } */
This patch adds a new effective-target function that tests whether
it is safe to emit the ROP-protect instructions and updates the
ROP test cases to use it.
Segher, as we discussed offline, this uses the double [] which you said
isn't needed in general regex's, but for some reason is needed in the
I'd like to ping the following patch.
Peter
On 10/27/21 8:37 PM, Peter Bergner via Gcc-patches wrote:
> PR102976 shows a test case where we generate wrong code when building
> a vector pair from 2 vector registers. The bug here is that with unlucky
> register assignments, we can
On 11/13/21 7:25 AM, Segher Boessenkool wrote:
> On Wed, Oct 27, 2021 at 08:37:57PM -0500, Peter Bergner wrote:
>> PR102976 shows a test case where we generate wrong code when building
>> a vector pair from 2 vector registers. The bug here is that with unlucky
>> register assignments, we can clobb
Getting back to this now that trunk is open again...
On 3/31/21 2:17 PM, Segher Boessenkool wrote:
> On Tue, Mar 30, 2021 at 06:49:29PM -0500, Peter Bergner wrote:
>> The mma_assemble_input_operand predicate does not accept reg+reg indexed
>> addresses which can lead to ICEs. The problem is that
Using an MMA builtin within an openmp parallel code block leads to an SSA
verification ICE on the temporaries we create while expanding the MMA builtins
at gimple time. The solution is to use create_tmp_reg_or_ssa_name(), which
knows when to create either an SSA or register temporary.
This fixes
The __builtin_vsx_assemble_pair and __builtin_mma_assemble_acc built-ins
currently assign their first source operand to the first VSX register
in a pair/quad, their second operand to the second register in a pair/quad, etc.
This is not endian friendly and forces the user to generate different calls
On 6/9/21 4:38 PM, Segher Boessenkool wrote:
> It is better if you *do* document the old names, but say "use the new
> stuff", I think? Or is there so little material with the old names
> out there that no one will notice?
The latter. There is only one user, but we want all new uses to use the
n
On 6/10/21 10:43 AM, Peter Bergner wrote:
> On 6/9/21 4:38 PM, Segher Boessenkool wrote:
>> Okay for trunk and 11 with at least that space fixed. Thanks!
>
> Ok, I'll retest with the above (but still removing the assemble
> built-in documentation) and push it if it's clean. Thanks!
Testing was
On 6/7/21 2:00 PM, Jeff Law wrote:
> I can't divulge many of the details right now, but one of the quirks of our
> architecture is that reg+d addressing modes for our vector loads/stores
> require
> the displacement to be aligned. This is an artifact of how these instructions
> are encoded.
Give
PR102976 shows a test case where we generate wrong code when building
a vector pair from 2 vector registers. The bug here is that with unlucky
register assignments, we can clobber one of the input operands before
we write both registers of the output operand. The solution is to use
early-clobbers
Sorry for reposting, but I forgot to CC the gcc-patches mailing list. :-(
PR101324 shows a problem in disabling shrink-wrapping when using -mrop-protect
when there is a attribute optimize/pragma. Martin's patch below moves handling
of flag_shrink_wrap so it gets re-disbled when we change or add
On 7/1/21 2:48 PM, Peter Bergner wrote:
> On 7/1/21 1:01 PM, Segher Boessenkool wrote:
>> The patch is okay for trunk.
>
> Below is the updated patch which is bootstrapping now. I'll commit it
> if it shows no regressions.
Testing was clean so I pushed it to trunk.
>> For the backports it is
On 7/4/21 11:32 AM, Bill Schmidt wrote
> On 7/1/21 2:48 PM, Peter Bergner via Gcc-patches wrote:
>> + if (d[1].icode != CODE_FOR_nothing)
>> + {
>> + op[nopnds++] = void_type_node;
>> + icode = d[1].icode;
>> + }
> T
On 7/6/21 3:08 PM, Bill Schmidt wrote:
> On 7/6/21 2:29 PM, Peter Bergner wrote:
>> These are RS6000_BTC_GIMPLE, so I think they should be handled within
>> the "if (gimple_func) ..." leg. That said, how about the following
>> change to resolve the issue you have? I'll kick off a bootstrap and
>>
On 7/6/21 5:05 PM, Segher Boessenkool wrote:
> On Tue, Jul 06, 2021 at 04:13:06PM -0500, Peter Bergner wrote:
>> On 7/6/21 3:08 PM, Bill Schmidt wrote:
>>> On 7/6/21 2:29 PM, Peter Bergner wrote:
These are RS6000_BTC_GIMPLE, so I think they should be handled within
the "if (gimple_func) .
On 7/7/21 11:55 AM, Peter Bergner wrote:
> On 7/6/21 5:05 PM, Segher Boessenkool wrote:
>> On Tue, Jul 06, 2021 at 04:13:06PM -0500, Peter Bergner wrote:
>>> On 7/6/21 3:08 PM, Bill Schmidt wrote:
On 7/6/21 2:29 PM, Peter Bergner wrote:
> These are RS6000_BTC_GIMPLE, so I think they should
The MMA build built-ins currently use individual lxv instructions to
load up the registers of a __vector_pair or __vector_quad. If the
memory addresses of the built-in operands are to adjacent locations,
then we could use an lxvp in some cases to load up two registers at once.
The patch below adds
On 7/8/21 6:28 PM, Segher Boessenkool wrote:
> It needs testing on BE.
Will do.
>> +static bool consecutive_mem_locations (rtx, rtx);
>
> Please don't; just move functions to somewhere earlier than where they
> are used.
Will do.
>> @@ -16841,8 +16843,35 @@ rs6000_split_multireg_move (rtx
On 7/8/21 8:26 PM, Peter Bergner wrote:
> We do need different code for LE versus BE. So you want something like
>
> if (WORDS_BIG_ENDIAN) {...} else {...}
>
> ...instead? I can try that to see if the code is easier to read.
[snip]
> Let me make the changes you want and I'll repost with what
On 7/9/21 6:14 PM, Peter Bergner wrote:
> ...code section. Does this look better? I'm currently running bootstraps
> and regtests on LE and BE.
Bootstrap and regtesting on both LE and BE showed no regressions.
Peter
On 7/10/21 7:39 PM, seg...@gate.crashing.org wrote:
> It is very hard to see the differences now. Don't fold the changes into
> one patch, just have the code movement in a separate trivial patch, and
> then the actual changes as a separate patch? That way it is much easier
> to review :-)
Ok, I
...and patch 2:
On 7/10/21 7:39 PM, seg...@gate.crashing.org wrote:
>> + unsigned subreg =
>> +(WORDS_BIG_ENDIAN) ? i : (nregs - reg_mode_nregs - i);
>
> This is not new code, but it caught my eye, so just for the record: the
> "=" should start a new line:
> unsig
On 7/13/21 12:14 PM, Peter Bergner wrote:
> ...and patch 2:
[snip]
> I'm currently bootstrapping and regtesting these two patches and
> will report back. Better now?
Ok, this along with the previous move patch bootstrapped and regtested
with no regressions on powerpc64le-linux.
Peter
On 7/13/21 5:59 PM, Segher Boessenkool wrote:
>> - && adjacent_mem_locations (str_mem, str_mem2))
>> + && adjacent_mem_locations (str_mem, str_mem2) != NULL_RTX)
>
> ... so don't change this? Or write != 0 != 0 != 0, if one time is good,
> three times must be better! :-
On 7/14/21 4:12 PM, Peter Bergner wrote:
> I'll make the change above and rebuild just to be safe and then commit.
Regtesting was clean as expected, so I pushed the commit to trunk. Thanks.
Is this ok for backporting to GCC 11 after a day or two on trunk?
Given GCC 10 doesn't have the opaque mod
On 5/10/21 7:52 AM, Pat Haugen wrote:
> On 5/7/21 6:00 PM, Segher Boessenkool wrote:
>> So what is this replaced with? Was it an "xxlmr" and it is just
>> unnecessary now?
>
> Different RA choice made the reg copy unnecessary.
>
> < xxspltib 0,8
> < xxlor 32,0,0
> ---
>> xxspltib 32
On 8/21/23 8:51 PM, Kewen.Lin wrote:
>> The following patch has been bootstrapped and regtested on powerpc64-linux.
>
> I think we should test this on powerpc64le-linux P8 or P9 (no P10) as well.
That's a good idea!
> I think this should be moved to be with the hunk on PCREL:
>
> /* If the
On 8/24/23 12:35 PM, Michael Meissner wrote:
> On Thu, Jul 20, 2023 at 10:05:28AM +0530, jeevitha wrote:
>> gcc/
>> PR target/110411
>> * config/rs6000/rs6000.h (enum rs6000_builtin_type_index): Add fields
>> to hold PTImode type.
>> * config/rs6000/rs6000-builtin.cc (rs6000_ini
On 8/24/23 12:56 AM, Kewen.Lin wrote:
> By looking into the uses of function rs6000_pcrel_p, I think we can
> just replace it with TARGET_PCREL. Previously we don't require PCREL
> unset for any unsupported target/OS, so we need rs6000_pcrel_p() to
> ensure it's really supported in those use place
On 8/25/23 6:20 AM, Kewen.Lin wrote:
> Assuming the current PCREL_SUPPORTED_BY_OS unchanged, when
> PCREL_SUPPORTED_BY_OS is true, all its required conditions are
> satisfied, it should be safe. while PCREL_SUPPORTED_BY_OS is
> false, it means the given subtarget doesn't support it, or one
> or mo
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/
We do not allow conversions between the MMA types and other types.
However, we are being too strict in not matching MMA types with
typdefs of those types. Use TYPE_CANONICAL to see through the
types to their canonical types before comparing them.
This is currently bootstrapping and regtesting. O
On 8/7/20 6:52 PM, Segher Boessenkool wrote:
> The element_mode vs. TYPE_MODE here does not matter, because we never
> deal with vector modes here, and they will error elsewhere anyway?
Agreed, TYPE_MODE is fine here.
> Okay for trunk if that is true (or with the necessary adjustments), and
> ok
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 retesting.
> I'll commit i
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
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 bootstrapping and regtesting. Ok for trunk
once that comes back clean?
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/rs6000-call.c (rs6000_promote_funct
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 need to save them to the stack, but
> the
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 bootstrapping and re
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
On 8/11/20 11:35 AM, Segher Boessenkool wrote:
> Hi Alan,
>
> On Tue, Aug 11, 2020 at 06:38:53PM +0930, Alan Modra wrote:
>> This fixes a fail when power10 isn't supported by binutils, and
>> ensures the test isn't run without power10 hardware or simulation on
>> the off chance that power10 insns
On 8/11/20 9:00 PM, Segher Boessenkool wrote:
> Not just params, but return values as well. "Error on MMA types in
> function prototype"?
Yes, it started out as a function param issue and then while working
on this, I decided I better look at what happens when they're used
as return values. I'll
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 enough to get rid of the wa
rs6000: ICE when using an MMA type as a function param or return value [PR96506]
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
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_tree type ATTRIBUTE_UNUSED,
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 type ATTRIBUTE_UNUSED,
>
On 8/13/20 3:00 PM, Carl Love wrote:
> On Thu, 2020-08-13 at 14:48 -0500, Bill Schmidt wrote:
>> OK, but that was just meant as an example. We have a fair number of
>> things that changed names, so I was somewhat surprised. It could be
>> that all of these are likewise hidden via the overload m
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
instructions which all end with "n". The only use of this instruction is in
an MMA conversion built-in function, so there is little to no compatib
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
>> instructions which all end
On 8/14/20 7:42 PM, Segher Boessenkool wrote:
> I think your current code is fine; I hadn't considered Bill's upcoming
> rewrite. It is more important to make that go smoother than to fix some
> aesthetics right now.
>
> Please check if the names for the builtins match the (future)
> documentatio
When we expand our MMA built-ins into gimple, we (me!) erroneously reused
the accumulator memory reference for both the source input value as well as
the destination output value. This led to a tree sharing error.
The solution is to create separate memory references for the input
and output values
On 9/1/20 12:38 PM, Segher Boessenkool wrote:
>> This passed 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 o
Generating arbitrary 64-bit constants on POWER can take up to 5 instructions.
However, some special constants can be generated in fewer instructions.
One special class of constants we don't handle, is constants that have one
set of consecutive 1-bits. These can be generated with a "li rT,-1"
follo
PR96125 shows a bug when we try to use an MMA built-in within a function
that uses #pragma target/attribute target to enable power10 code generation
and the -mcpu= command line option is pre-power10.
The problem is that we only initialize built-ins once, fairly early, when
the command line options
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?
>
> Peter
>
>
> gcc/
> PR
On 7/9/20 12:11 PM, Segher Boessenkool wrote:
>> gcc/testsuite/
>> PR target/96125
>> * gcc.target/powerpc/pr96125.c: New test.
>
> Okay for trunk and 10 (but see test nit below). Thanks!
[snip]
> So maybe we should just do all builtins always?
I think that is the correct thing to do,
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 do that tomorrow.
Bill's nightly testsuit
PR92488 shows we do not generate hardware conversion instructions when
converting from _Decimal128 to _Decimal32. There is no one instruction
that does the conversion, so we currently call the __dpd_trunctdsd2
function to do the conversion for us. This is slow. Paul Murphy
described a short sequ
On 7/17/20 3:23 PM, Segher Boessenkool wrote:
> On ISA 3.0B and later you can do
>
> mffscdrni %3,7
> drdpq %2,%1
> mffscdrn %3,%3
> drsp %0,%2
>
> (saving one insn, and using somewhat cheaper insns). But that is only
> on newer machines, so is this worth it at all? :-)
On 7/17/20 4:32 PM, Segher Boessenkool wrote:
> Well, just make an "isa" value of "p9"? Then you can just do
>
> (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_scratch:T
101 - 200 of 298 matches
Mail list logo
