On 3/14/22 10:06 PM, Peter Bergner wrote:
> On 3/14/22 8:24 PM, Segher Boessenkool wrote:
>> You might want to name that common expression, "rtx addr = XEXP (op, 0);"
>> or something. Dunno what is best
>
> Will do.
>
>
>> Please put that new MEM_
On 3/4/22 8:14 PM, Peter Bergner wrote:
> On 3/4/22 11:33 AM, Peter Bergner wrote:
>>> Ok pushed to trunk. I haven't determined yet whether we need this on GCC
>>> 11 yet.
>>> I'll check on that and report back. Thanks!
>>
>> I've confirm
On 3/16/22 7:33 AM, Segher Boessenkool wrote:
> On Tue, Mar 15, 2022 at 02:49:39PM -0500, Peter Bergner wrote:
>> The trunk patch has been confirmed to fix the glibc build errors and no
>> issues
>> with the patch has surfaced, so ok for the GCC11 and GCC10 release bran
regression testing with no regressions on powerpc64le-linux.
Ok for trunk?
Peter
gcc/testsuite/
* g++.dg/pr65240-1.C: Use -mdejagnu-cpu=. Remove dg-skip-if.
* g++.dg/pr65240-2.C: Likewise.
* g++.dg/pr65240-3.C: Likewise.
* g++.dg/pr65240-4.C: Likewise.
* g
On 3/25/22 4:08 PM, Segher Boessenkool wrote:
> On Fri, Mar 25, 2022 at 02:51:38PM -0500, Peter Bergner wrote:
>> This patch updates the POWER testsuite test cases using -mcpu= and -mtune=
>> to use the preferred -mdejagnu-cpu= and -mdejagnu-tune= options. This also
>> obvi
the -mcpu=power10 that the test case uses.
That said, I agree, pr101849.c should probably be copied into another test case
file (pr103353.c) that uses options that trigger the issue so we can be sure the
fix won't regress.
Peter
strap and regtesting on powerpc64le-linux with no regressions.
Ok for trunk?
This is marked as a GCC 11/12 regression. Ok for a GCC 11 backport after
some burn-in on trunk?
Peter
gcc/
PR target/104894
* config/rs6000/rs6000.cc (rs6000_sibcall_aix): Handle pcrel sibcalls
On 4/5/22 5:32 PM, Segher Boessenkool wrote:
> On Tue, Apr 05, 2022 at 05:06:50PM -0500, Peter Bergner wrote:
>>
>> + /* Handle longcall attributes. */
>> + if ((INTVAL (cookie) & CALL_LONG) != 0
>> + && GET_CODE (func_desc) == SYMBOL_REF)
>
On 4/5/22 10:33 PM, Peter Bergner via Gcc-patches wrote:
> On 4/5/22 5:32 PM, Segher Boessenkool wrote:
>> On Tue, Apr 05, 2022 at 05:06:50PM -0500, Peter Bergner wrote:
>>>
>>> + /* Handle longcall attributes. */
>>> + if ((INTVAL (cookie) & CALL_LONG
On 4/11/22 4:13 PM, Segher Boessenkool wrote:
> On Wed, Apr 06, 2022 at 02:33:52PM -0500, Peter Bergner wrote:
>> On 4/5/22 10:33 PM, Peter Bergner via Gcc-patches wrote:
>>> On 4/5/22 5:32 PM, Segher Boessenkool wrote:
>>>> On Tue, Apr 05, 2022 at 05:06:50PM -0500,
in so we can get it backported.
I'm being pinged about this from a customer who is using GCC10 and this issue
is holding them back, so the quicker we get this in, the better.
Peter
atch for weeks, and I do it again now.
Did you NAK the patch due to its specific implementation or are you
even against the aim of the patch, namely that gcc configure tries
to determine the long double default of the underlying system and
matches that?
Peter
can test
for or do you think that's impossible and we'll just have to live with
explicitly using a configure option to set the default?
...at least until some time in the far future when enough systems/distros
have changed to IEEE128 that we can change the default without a test.
Peter
below, I
haven't seen the test case fail in over 1 million runs.
Ok for trunk and backports to the release branches?
Peter
gcc/testsuite/
* gcc.target/powerpc/htm-1.c: Retry intermittent failing tbegins.
diff --git a/gcc/testsuite/gcc.target/powerpc/htm-1.c
b/gcc/testsuite/gcc.t
On 2/15/22 3:54 PM, Segher Boessenkool wrote:
> On Tue, Feb 15, 2022 at 01:03:09PM -0600, Peter Bergner wrote:
>> The HTM tbegin. instruction can fail intermittently due to many reasons.
>
> Just a few really. But, if the transaction fails it will appear as if
> the tbegin. ha
ems. I use the Quicktext addon/extension
and it gives me a toolbar option "Other" which has a "Insert file as text"
which allows adding a patch to your email inline with no whitespace munging.
Peter
Sorry for dropping the ball on testing the patch from the bugzilla!
The following patch fixes the ICE reported in the bugzilla on the pre-existing
gcc testsuite test case, bootstraps and shows no testsuite regressions
on powerpc64le-linux. Ok for trunk?
Peter
For -ftrivial-auto-var-init
On 11/30/21 2:37 AM, Richard Biener wrote:
> On Mon, Nov 29, 2021 at 11:56 PM Qing Zhao wrote:
> I think that's inconsistent indeed. Peter, what are "opaque"
> registers? rs6000-modes.def suggests
> that there's __vector_pair and __vector_quad, what's th
r *dst, __vector_pair *src)
{
__vector_pair pair;
pair = *src;
...
}
We do not accept things like:
acc = 0;
acc = {0, 0, ... };
etc.
Peter
itialized memory.
As for what src points to, that could be initialized how any other memory/
array could be initialized, so either a static array, read in some data
from a file into an array, compute the array values in a loop, etc. etc.
Peter
a from memory that represents a (partial) row of a matrix.
For __vector_quad, it too lives in a register (accumulator register) and
represents a small matrix. We have the __builtin_mma_xxsetaccz (&acc)
builtin to initialize it to a zero constant.
Peter
On 12/1/21 9:06 AM, Qing Zhao wrote:
>> On Dec 1, 2021, at 3:01 AM, Richard Biener
>> wrote:
>> Given all this I suggest to exempt OPAQUE_TYPE from is_var_need_auto_init
>> instead of fixing up things at expansion time.
>
> Agreed.
>
> So
On 12/1/21 3:01 AM, Richard Biener wrote:
> Given all this I suggest to exempt OPAQUE_TYPE from is_var_need_auto_init
> instead of fixing up things at expansion time.
The following fixes the ICE. The bootstrap/regtesting is still running though.
Peter
diff --git a/gcc/gimplify.c
On 12/1/21 1:07 PM, Richard Biener wrote:
> On December 1, 2021 6:42:21 PM GMT+01:00, Peter Bergner
> wrote:
>> On 12/1/21 3:01 AM, Richard Biener wrote:
>>> Given all this I suggest to exempt OPAQUE_TYPE from is_var_need_auto_init
>>> instead of fixing up thing
I'd like to ping the following patch.
The test case in the previously OK'd fix for PR101324 depends on this change,
so I've had to hold off committing it until this is in. Thanks.
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584208.html
Peter
Message-ID:
Th
ah, in this case * == "".
> Okay for trunk. Thanks!
Thanks, pushed.
Peter
On 10/29/21 4:45 PM, Segher Boessenkool wrote:
> On Wed, Oct 27, 2021 at 10:17:39PM -0500, Peter Bergner wrote:
>> 2021-10-27 Martin Liska
>>
>> gcc/
>> PR target/101324
>> * config/rs6000/rs6000.c (rs6000_option_override_internal): Move the
>>
On 12/3/21 2:39 PM, Peter Bergner wrote:
> On 10/29/21 4:45 PM, Segher Boessenkool wrote:
>> On Wed, Oct 27, 2021 at 10:17:39PM -0500, Peter Bergner wrote:
>>> 2021-10-27 Martin Liska
>>>
>>> gcc/
>>> PR target/101324
>>> * config/r
On 12/3/21 3:27 PM, Peter Bergner wrote:
> On 12/3/21 2:39 PM, Peter Bergner wrote:
>> On 10/29/21 4:45 PM, Segher Boessenkool wrote:
>>> On Wed, Oct 27, 2021 at 10:17:39PM -0500, Peter Bergner wrote:
>>>> 2021-10-27 Martin Liska
>>>>
>>>>
t; it can also make the below case different.
I thought Martin and richi mentioned that target attribute options
are treated as if they are appended to the end of the command line
options, so they can potentially override earlier options, but they
don't actually ignore them?
Peter
On 12/2/21 4:24 PM, Segher Boessenkool wrote:
> On Thu, Dec 02, 2021 at 10:43:24AM -0600, Bill Schmidt wrote:
>> The new built-in infrastructure is now enabled!
>
> Congratulations, and thanks for all the work!
A big +1!
Peter
On 12/6/21 3:35 AM, Martin Liška wrote:
> On 12/4/21 00:23, Peter Bergner wrote:
>> I thought Martin and richi mentioned that target attribute options
>> are treated as if they are appended to the end of the command line
>> options, so they can potentially override earl
default. If the user explicitly used
-fno-htm on the function, then we should not inline the htm function
into it. Ditto for the other way around. Meaning, the caller's
option flags should be a superset of the callee's flags, but the
explicit flags used on both functions need to match exactly.
Peter
ow we
correctly run the rop tests on LE and mark them as UNSUPPORTED on BE.
Ok for trunk?
Peter
gcc/testsuite/
PR target/103556
PR target/103586
* lib/target-supports.exp (check_effective_target_rop_ok): Use expr {}.
diff --git a/gcc/testsuite/lib/target-supports.exp
On 12/7/21 12:20 PM, Peter Bergner wrote:
> proc check_effective_target_rop_ok { } {
> -return [check_effective_target_power10_ok]
> - && [check_effective_target_powerpc_elfv2]
> +return [expr { [check_effecti
directory as
expected, rather than just the root library directory as occurs when an
unsupported target is selected (for instance, rv32id).
Signed-off-by: Peter Marheine
---
gcc/config/riscv/t-elf-multilib | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/gcc/config/riscv
* sched-rgn.cc (save_state_for_fallthru_edge): New function.
(schedule_region): Use it for all blocks.
Peter
ss
of the pointer type being used.
This passed bootstrap and regtesting on powerpc64le-linux with no regressions.
Ok for trunk and backports after some burn-in time?
Peter
gcc/
PR target/101322
* config/rs6000/rs6000-builtin.cc (rs6000_gimple_fold_mma_builtin):
Enforce the u
code altogether.
This passed bootstrap and regtesting on powerpc64le-linux with no regressions.
Ok for trunk and backports after some burn-in time?
Peter
gcc/
PR target/106017
* config/rs6000/rs6000.cc (rs6000_invalid_conversion): Remove handling
of MMA pointer conversions
> Okay for trunk and all backports. Thanks!
Ok, pushed to trunk. I'll backport after some burn-in. Thanks!
Peter
Ping; any comments on this?
> rv32iafc-ilp32 is compatible with rv32iac-ilp32 for library
> implementation, so add a reuse rule allowing the default configuration
> to support rv32iafc.
On 8/27/22 7:47 PM, Peter Bergner via Gcc-patches wrote:
> On 8/27/22 4:37 PM, Segher Boessenkool wrote:
>>> The fix is to just remove the MMA pointer conversion
>>> handling code altogether.
>>
>> Okay for trunk and all backports. Thanks!
>
> Ok, pushed t
I'd like to ping the following patch.
Peter
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600451.html
Message-ID:
>When we expand an MMA disassemble built-in with C++ using a pointer that
>is casted to a valid MMA type, the type isn't passed down to the expand
&
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 (
ejagnu-64
options that operate like our -mdejagnu-cpu= options and override any
-m32/-m64 option given on the command line (eg, RUNTESTFLAGS=...).
To be honest, I'm not sure how I feel about this suggestion! :-)
Maybe we'd only use it on the test cases like this one that we know
are sensitive to be overridden???
Peter
nexpectedly.
>
> It's meant to update "lxv" to "p?lxv" and should leave the
> "lvx" unchanged. So this is to fix the typo accordingly.
I agree. Thanks for catching this!
Peter
principle of least surprise.
I think I agree with this, since -mpowerpc64 doesn't mean or imply -m64.
I say "think", because I don't remember the history of why it behaves this
way and maybe there was a reason we did like this? If there isn't a reason,
then I'm all for -m32 not overriding -mpowerpc64.
Peter
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
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;
>
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
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 n
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
>
trunk and backports after some burn-in time?
Peter
gcc/
PR target/101322
* config/rs6000/rs6000-builtin.cc (rs6000_gimple_fold_mma_builtin):
Enforce the use of a valid MMA pointer type.
gcc/testsuite/
PR target/101322
* g++.target/powerpc/pr101322.C: New test.
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
ook into this, please let me know. I'd like to know what you
find out.
Peter
evious insn, so not ideal.
It's too bad we don't have a paddis or poris insns where we could specify
in the prefix a shift of 32-bits rather than the normal 16-bits.
If we had those, we could generate the constant with just 2 64-bit insns.
Peter
eeded? Or maybe we do to make other potential backports easier?
I'm fine either way.
Peter
gcc/
* config/rs6000/rs6000-builtin.cc (rs6000_gimple_fold_mma_builtin): Use
NOP_EXPR for MMA pointer casting.
diff --git a/gcc/config/rs6000/rs6000-builtin.cc
b/gcc/config/rs6000/rs
all related to pointers to vectors and I remember
you mentioning that as one of the reasons for using VIEW_CONVERT_EXPR over
NOP_EXPR, so I left them alone to be safe.
> Okay for trunk. Thanks!
Ok, pushed to trunk. Thanks!
Peter
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 relate
or_quad", no type "__vector_quad".
>
> 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) __vector_pair or __vector_quad to be
used as actual arguments to non-builtin functions. We do allow
pointers to those types though.
Peter
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.
>>
specifically GCC 10?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059#c31
Peter
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?
>>
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 dire
mp;= ~(OPTION_MASK_P8_FUSION
>| OPTION_MASK_P10_FUSION);
>explicit_isa &= ~(OPTION_MASK_P8_FUSION
> | OPTION_MASK_P10_FUSION);
>
I can add that to the simple patch while we wait for the bigger patch.
Peter
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_i
less/until we have a
test case that exhibits the issue, I'm only asking for a backport to
GCC12 which does show the performance problem.
Peter
gcc/
PR target/105556
* config/rs6000/mma.md (mma_, mma_, mma_, mma_,
mma_, mma_, mma_, mma_,
mma_, mma_, mma_,
the 'v' usage, but I'll see how it works.
If it works and simplifies the patch, great! I'll report back.
> Okay for trunk with a slightly better changelog. Thanks!
If it doesn't work, I'll go with the code as is, modulo the
changes you asked for. Thanks.
Peter
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 :-)
&g
anch after some burn-in time on
trunk?
Technically, the same issue exists in GCC11 and GCC10, but the RA
assignment is OK with the current code, so unless/until we have a
test case that exhibits the issue, I'm only asking for a backport
to GCC12 which does show the performance problem.
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")
>> -(unspe
sions.
Ok for mainline and the GCC 10 release branch after some burn in?
Peter
gcc/
* config/rs6000/rs6000.h (BIGGEST_ALIGNMENT): Revert previous commit
so as not to break the ABI.
* config/rs6000/rs6000-call.c (rs6000_init_builtins): Set the ABI
mandated alignmen
ARGET_EXTRA_BUILTINS which
is a conglomeration of a lot of different target flags. The hard float
test seemed like the test that would allow it to be run on the most
targets, but being disabled when it should be. Yeah, we can fix it
if we trip over it somehow.
Peter
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 res
moved. I could either remove the comment altogether or change it
to:
;; We can't have integer constants in XOmode so we wrap this in an
;; UNSPEC_VOLATILE.
...to refer to the dummy zero for the source. Let me know what you want.
>> (set_attr "length" "4")])
>
> Not new of course: the default length is 4, most insns have that, it
> helps to be less verbose.
I'll remove that before pushing, thanks!
Peter
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
>> "Remo
here.
That said, this does fail on GCC11 and GCC10 (not sure about earlier, haven't
tried them yet), so we will need some type of fix for the releases. I do think
your concern about not having some checking elsewhere is valid, unless there
already is some checking there and you and I are just not aware of it.
Peter
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 &q
needed in the gcc
testsuite regex.
Tested on powerpc64le*-linux with no regressions. Ok for mainline?
Peter
gcc/testsuite/
* lib/target-supports.exp (check_effective_target_rop_ok): New function.
* gcc.target/powerpc/rop-1.c: Use it.
* gcc.target/powerpc/rop-2.c
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
>> registe
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
the ICE and bootstraps and regtests with no regressions.
Ok for trunk?
The same ICE occurs in GCC 11 and GCC 10. Ok to backport to those release
branches after some burn in on trunk?
Peter
gcc/
PR target/100777
* config/rs6000/rs6000-call.c (rs6000_gimple_fold_mma_builtin): Use
I also verified that we continue
to generate the same code as before on some small unit tests and that we
agree with what LLVM generates. Ok for trunk?
I'd also like to backport this in time for gcc 11.2. Ok for the release
branch after it has baked on trunk for a few days?
Peter
gcc/
>> + int index = WORDS_BIG_ENDIAN ? i: nvecs - 1 - i;
>
> Space before colon.
Ah, thanks for catching that!
> 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!
Peter
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
. The DS and DQ operands
have the same maximum displacement as D operands, we just force that their
bottom 2-bits/4-bits must be zero, so we don't need to include them in the
insn encoding. I believe this is all just handled in our legitimate address
routines, but maybe Segher and/or Mike can correct me if I'm wrong?
Peter
-clobbers in the assemble pair and accumulator patterns.
This passed bootstrap and regtesting with no regressions and our
OpenBLAS team has confirmed it fixes the issues they reported.
Ok for mainline?
Ok for GCC 11 too after a few days on trunk?
Peter
gcc/
PR target/102976
* config
r add options.
This passed bootstrap and regtesting with no regressions. Segher, you
approved Martin's patch in the bugzilla. Is the test case ok too?
I'll note the test case uses the "new" rop_ok effective-target function which
I submitted as a separate patch.
Peter
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.
>
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?
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 wi
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:
>>>>>
in on trunk, if that is ok?
Given the MMA redesign from GCC 10 to GCC 11, I have no plans to
backport this to GCC 10.
Peter
gcc/
* config/rs6000/rs6000.c (consecutive_mem_locations): New function.
(rs6000_split_multireg_move): Handle MMA build built-ins with operands
My thought was to write a simple pass run at about
the same time as our swap optimization pass to look for adjacent
lxv's and stxv's and convert them into lxvp and stxvp. However, that
won't catch the above case, since the assemble/build pattern is not
split until very late, so we still want the above change.
Also, given the new pass will be more complicated than the above code,
it will be a GCC 12 only change.
Let me make the changes you want and I'll repost with what I come up with.
Peter
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&#
1901 - 2000 of 2388 matches
Mail list logo
