&cc_use_insn))
> + && COMPARISON_P (*cc_use_loc))
Line 3167 already is
&& GET_CODE (SET_SRC (PATTERN (i3))) == COMPARE
so what in your backend is unusual?
Segher
On Thu, Mar 07, 2024 at 11:22:12AM +0100, Richard Biener wrote:
> > > > Undo the combination if *cc_use_loc is not COMPARISON_P.
Why, anyway? COMPARISON_P means things like LE. It does not even
include actual RTX COMPARE.
Segher
taken care of that ;-)
All as documented.
Segher
ses.
Yup. That is the whole point of find_single_use: if that test fails,
combine knows to get its paws off :-)
Segher
loc, 0), ...)
>
> on unspec, which has no XEXP (..., 0).
>
> And *this* is what triggers RTX checking assert.
The unspec should have the CC compared with 0 as argument.
Segher
w you want me
> to structure the patches.
*You* should know the code already, so you surely can figure out a nice
way to present it, so that it takes me LESS work to review this than it
took you to write it?
Making a patch series reviewable is part of the development effort. It
is way less work if you start with this as the goal in mind. It is less
work than writing (and debugging etc.) an omnibus patch, in the first
place!
Your goal is to make a patch series that will be reviewed and then seen
to be great stuff. So it of course needs to *be* great stuff, but it
also needs to be presented in such a way that that is obvious.
Segher
On Thu, Mar 07, 2024 at 11:07:18PM +0100, Uros Bizjak wrote:
> On Thu, Mar 7, 2024 at 10:37 PM Segher Boessenkool
> wrote:
> > > but can be something else, such as the above noted
> > >
> > > (unspec:DI [
> > > (reg:CC 17 flags)
> > >
RS6000_BTI_ptr_long_long_unsigned,
> + RS6000_BTI_PTI,
Please call it RS6000_BTI_INTPTI, to be more in line with the naming of
other things.
With that fixed it should be good. Please repost with a good commit
comment and changelog :-)
Thanks,
Segher
treme example look at 390, but on pretty
much any target both signed and unsigned comparisons use the same flag
bits, and maybe fp comparisons as well.
But pushfl does sound like pure dataflow. Why is this a builtin, is
it ever a good idea if the user writes stuff the compiler can do a
better job doing itself, not to mention it is way easier for the
compiler anyway? :-)
Segher
; register here.
So you can use an unspec just to convert the flags reg to an integer?
To make an integer representation of flags reg contents.
Or is that what we started with here?
Segher
this is not the
way to do it.
Committed to trunk.
Segher
2024-03-27 Segher Boessenkool
PR rtl-optimization/101523
* combine.cc (try_combine): Don't do a 2-insn combination if
it does not in fact change I2.
---
gcc/combine.cc | 11 +++
1 file change
but we need to do an actual uncse first!
Somewhere before combine, and then redo a CSE after it. An actual CSE,
not doing ten gazillion other things.
Segher
had to share it! Worth the
> testsuite churn anyway. :)
>
> Segher, if you end up reverting r14-9692-g839bc42772ba7a (as
> unfortunately seems not unlikely), then please also revert this
> commit: r14-9799-g4c8b3600c4856f7915281ae3ff4d97271c83a540.
I won't revert it, it fixes
on.
This is never okay. You cannot commit a patch without approval, *ever*.
That patch is also obvious -- obviously *wrong*, that is. There are
big assumptions everywhere in the compiler how a CC reg can be used.
This violates that, as explained elsewhere.
Segher
On Wed, Apr 10, 2024 at 08:32:39PM +0200, Uros Bizjak wrote:
> On Wed, Apr 10, 2024 at 7:56 PM Segher Boessenkool
> wrote:
> > This is never okay. You cannot commit a patch without approval, *ever*.
This is the biggest issue, to start with. It is fundamental.
> > That pat
future patches in a separate series, first.
I'll comment on that patch in a minute, you'll probably want to take
those comments into consideration before posting that series ;-)
Segher
in future patches.
Don't randomly reorder, either.
_FUTURE should be added after POWER11.
> > I think we should also update asm_names in driver-rs6000.cc.
>
> Ok. Though the driver-rs6000.cc stuff won't kick in until we have a real
> system that matches "future".
Or when during development you have that faked. You did test it, right?
:-)
Segher
e do currently
> for option conflict errors emission. But I'm fine for either.
Whatever is easiest.
Segher
t. If the user
"At the moment" is out of date almost as soon as you write it. It is
better to avoid such terms ;-)
> + explicitly tried to use -mtune=future, give a warning. If not, use the
> + power10 tuning until future tuning is added. */
There should be Power11 tuning now, please use that?
So please post this -- as a separate series, and not as a single patch --
after fixing the things Ke Wen pointed out. Thanks!
Segher
On Thu, Feb 15, 2024 at 07:34:32PM +, Sam James wrote:
> I have now started doing this in PR113932.
Thank you!
Segher
On Thu, Feb 15, 2024 at 08:41:42PM -0500, Paul Koning wrote:
> > On Feb 15, 2024, at 5:56 PM, Segher Boessenkool
> > wrote:
> >
> > On Thu, Feb 15, 2024 at 07:34:32PM +, Sam James wrote:
> >> I have now started doing this in PR113932.
> >
> > Th
always available.
The downside of the VAX situation of course is that the compiler has no
freedom to optimise the frame and *logue code at all, let alone well.
This may not matter so much on narrow ucoded in-order machines, there
are different balances there :-)
Segher
Hi!
On Tue, Jan 16, 2024 at 10:50:01AM +0800, Kewen.Lin wrote:
> As PR109987 and its duplicated bugs show, -mno-power8-vector
> (and -mno-power9-vector) cause some problems and as Segher
> pointed out in [1] they are workaround options, so this patch
> is to remove -m{no,}-power{
t considering we raise error for -mno-vsx -mpower{8,9}-vector
> before, without specifying -mvsx is closer to the previous.
>
> I'll adjust it and the below similar ones, thanks!
It is never supported to do unsupported things :-)
We need to be able to rely on defaults. Otherwise, we will have to
implement all of GCC recursively, in itself, in the testsuite, and in
individual tests. Let's not :-)
Cheers,
Segher
the compiler has fewer bugs :-)
Segher
t's the
essence of good patchsets: one change per patch.
And then the commit message can be simple as well, and the chanegelog
will be easy to write. That is the litmus test for good patch series :-)
Segher
rs6000.h:#define PROCESSOR_DEFAULT64 PROCESSOR_RS64A
> gcc/config/rs6000/vxworks.h:#define PROCESSOR_DEFAULT PROCESSOR_PPC604
>
> , and they are unlikely to be updated later, no?
In most cases did would be an ABI change. Almost never an acceptable
thing to do.
Segher
operand, always).
I'm not saying we do not want to restrict these things, but a commit
that doesn't discuss this at all is not okay. Sorry.
Segher
On Tue, Feb 27, 2024 at 04:50:02PM -0600, Peter Bergner wrote:
> On 2/27/24 6:40 AM, Segher Boessenkool wrote:
> > On Tue, Feb 27, 2024 at 02:02:38AM +0530, jeevitha wrote:
> > input_operand allows a lot of things that splat_input_operand does not,
> > not just imm
On Wed, Feb 28, 2024 at 11:58:15AM -0600, Peter Bergner wrote:
> 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
fix the port's RTX
> costs.
Or implement the insn_cost hook instead, it will be used preferably over
rtx_costs in most places then. Including in the combiner. insn_cost
is much easier to implement, and even possible to make good cost
estimates with :-)
Segher
> The pass currently has a single objective: remove definitions by
> substituting into all uses.
The easy case ;-)
Segher
and:DI 0 "register_operand" "=r")
> (unspec:DI [(match_operand:DF 1 "vsx_register_operand" "wa")]
>UNSPEC_VSX_SXSIG))]
> - "TARGET_P9_VECTOR && TARGET_64BIT"
> + "TARGET_P9_VECTOR && TARGET_POWERPC64"
That is a good fix, separate from the rest though, so could you do it
first please?
Segher
Hi!
On Thu, Dec 01, 2022 at 08:26:52AM +0100, Richard Biener wrote:
> On Thu, Dec 1, 2022 at 12:26 AM Segher Boessenkool
> wrote:
> > On Wed, Nov 30, 2022 at 03:16:25PM -0300, Adhemerval Zanella via
> > Gcc-patches wrote:
> > > clang by default rejects the input cast
On Mon, Dec 12, 2022 at 02:10:16PM -0300, Adhemerval Zanella Netto wrote:
> On 30/11/22 20:24, Segher Boessenkool wrote:
> > I understand that the casts should be no-ops on the asm side (maybe they
> > change the sign) and they are present as type-checking. Can we implement
> &g
t; I will send out a replacement patch for it.
Please send a complete new series replacing this one. Thanks.
Segher
On Tue, Dec 06, 2022 at 04:03:35PM +0100, Jakub Jelinek wrote:
> On Tue, Dec 06, 2022 at 08:56:09AM -0600, Segher Boessenkool wrote:
> > > In the past, _Float128 was a C extended type,
> > > but now it is a part of the C/C++ 2x standards.
> >
> > Only if
for extern functions (like this one) because the function
implementation is always farther away so you do not easily have all
interface details in mind. Good names help :-)
> +(define_code_iterator eqne [eq ne])
> +(define_code_attr EQNE [(eq "EQ") (ne "NE")])
Just or should work?
Please fix these things. Almost there :-)
Segher
POWER10 whenever you check for TARGET_P10_FUSION; but there
really is no reason at all to disable P10 fusion on other CPUs (neither
newer nor older!).
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr104024-1.c
> @@ -0,0 +1,16 @@
> +/* { dg-require-effective-target int128 } */
> +/* { dg-options "-O1 -mdejagnu-cpu=power6 -mpower10-fusion" } */
Does this need -O1? If not, use -O2 please; if so, document it.
Segher
rward in a meaningful way until these problems are
fixed. We can move around like headless chickens some more of course.
Segher
es with the same mode having different
precision is not so very reasonable, and will likely cause other
problems as well.
We cannot use precision to order modes or types, that is the core
problem. A conversion from IEEE QP to double-double (or vice versa) is
neither widening nor narrowing.
Segher
On Thu, Dec 15, 2022 at 07:56:14PM +0100, Jakub Jelinek wrote:
> On Thu, Dec 15, 2022 at 12:49:27PM -0600, Segher Boessenkool wrote:
> > Certainly. But different types with the same mode having different
> > precision is not so very reasonable, and will likely cause other
>
Hi!
On Thu, Dec 15, 2022 at 07:09:38PM -0500, Michael Meissner wrote:
> On Thu, Dec 15, 2022 at 11:59:49AM -0600, Segher Boessenkool wrote:
> > On Wed, Dec 14, 2022 at 10:36:03AM +0100, Jakub Jelinek wrote:
> > > The hacks with different precisions of powerpc 128-bit floating ty
On Wed, Dec 14, 2022 at 04:26:54PM +0800, Jiufu Guo wrote:
> Segher Boessenkool writes:
> > On Mon, Aug 29, 2022 at 11:42:16AM +0800, Jiufu Guo wrote:
> >> li %r9,-1
> >> rldicr %r9,%r9,0,0
> >> cmpd %cr0,%r3,%r9
> >
> > FWIW
d for the other
> function names "lioris" and "lisrldicl".
Ha yes, that last one is a bit impregnable like this. It is testsuite
so everything goes of course, but :-)
Segher
t; * gcc.target/powerpc/pr106708.c: New test.
Okay for trunk with the nits Ke Wen pointed out taken care off.
Thanks!
Segher
are
just a few FAILs.
Committed.
Segher
2022-12-17 Segher Boessenkool
* config/rs6000/rs6000-logue.cc (rs6000_output_function_epilogue):
Handle GNU Rust for the tbtab lang field.
---
gcc/config/rs6000/rs6000-logue.cc | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/
/
> +/* { dg-do compile { target has_arch_ppc64 } } */
> +
> +/* { dg-final { scan-assembler-times {\mcmpldi\M} 10 } } */
> +/* { dg-final { scan-assembler-times {\mcmpdi\M} 4 } } */
> +/* { dg-final { scan-assembler-times {\mrotldi\M} 14 } } */
> +
With so much going on in just one function, I am a bit worried that this
testcase will easily fail in the future. We will see.
Okay for trunk with those i's dotted. Thank you!
Segher
2.1).
And GCC just does a copy, already? At -O2 anyway.
> I think the posted patch is good for consistency, treating conversion to the
> same format sometimes as convertFormat and sometimes as copy is maybe valid
> but confusing, especially when on:
Agreed.
Segher
Hi!
On Mon, Dec 19, 2022 at 02:13:49PM +0800, Kewen.Lin wrote:
> on 2022/12/15 06:29, Segher Boessenkool wrote:
> > On Wed, Nov 30, 2022 at 04:30:13PM +0800, Kewen.Lin wrote:
> >> --- a/gcc/config/rs6000/genfusion.pl
> >> +++ b/gcc/config/rs6000/genfusion.pl
&
is, it was harder to write as well, write changelog
for, etc. Often when you prepare patches it becomes apparent that you
should have structured things a bit differently. That is a good time to
do exactly so :-)
> This patch keeps outer interfaces of these builtins unchanged.
Of course. This patch doesn't edit any builtins, it changes only the
machine description. "Of the corresponding builtins" :-)
Segher
On Wed, Dec 14, 2022 at 07:21:20PM +0800, Kewen.Lin wrote:
> I'm going to push this next week if no objections.
Please do?
Segher
imum over all values in that format gives
double-double the same precision as IEEE DP, not useful in any practical
way either :-/
> --- a/gcc/tree.cc
> +++ b/gcc/tree.cc
> @@ -9442,15 +9442,6 @@ build_common_tree_nodes (bool signed_char)
>if (!targetm.floatn_mode (n, extended).exists (&mode))
> continue;
>int precision = GET_MODE_PRECISION (mode);
> - /* Work around the rs6000 KFmode having precision 113 not
> - 128. */
It has precision 126 now fwiw.
Joseph: what do you think about this patch? Is the workaround it
removes still useful in any way, do we need to do that some other way if
we remove this?
Segher
Hi!
On Wed, Dec 21, 2022 at 09:40:24PM +, Joseph Myers wrote:
> On Wed, 21 Dec 2022, Segher Boessenkool wrote:
> > > --- a/gcc/tree.cc
> > > +++ b/gcc/tree.cc
> > > @@ -9442,15 +9442,6 @@ build_common_tree_nodes (bool signed_char)
> > >if (!t
cisions
can be made, and then later we just have to translate the "low Gimple"
or "RTL-Gimple" ("Rimple"?) to RTL. A format that is looser in many
ways than either RTL or Gimple. A bit like Generic in that way.
Segher
On Wed, Dec 21, 2022 at 11:41:58AM +0800, Kewen.Lin wrote:
> on 2022/12/20 21:19, Segher Boessenkool wrote:
> > Sure, I understand that. What I don't like is the generator program is
> > much too big and unstructured already, and this doesn't help at all; it
> >
On Thu, Dec 22, 2022 at 07:48:28PM +, Joseph Myers wrote:
> On Thu, 22 Dec 2022, Segher Boessenkool wrote:
> > On Wed, Dec 21, 2022 at 09:40:24PM +, Joseph Myers wrote:
> > > On Wed, 21 Dec 2022, Segher Boessenkool wrote:
> > > > Joseph: what do you t
reg:SI) 0) to express a 32-bit
integer bitcast to an IEEE SP number, and our machine description should
make it work nicely.
Segher
On Fri, Dec 23, 2022 at 05:20:09PM +0100, Richard Biener wrote:
> > Am 23.12.2022 um 15:48 schrieb Segher Boessenkool
> > :
> > None of this belongs in generic code at all imo. At expand time it
> > should be expanded to something that works and can be optimised well,
On Fri, Dec 23, 2022 at 08:13:48PM +0100, Richard Biener wrote:
> > Am 23.12.2022 um 17:55 schrieb Segher Boessenkool
> > :
> > There are at least six very different kinds of subreg:
> >
> > 0) Lvalue subregs. Most archs have no use for it, and it can be
> &g
Hi!
On Wed, Oct 12, 2022 at 04:12:21PM +0800, Kewen.Lin wrote:
> PR106680 shows that -m32 -mpowerpc64 is different from
> -mpowerpc64 -m32, this is determined by the way how we
> handle option powerpc64 in rs6000_handle_option.
>
> Segher pointed out this difference should be t
ance) in
general (and maybe even without such a reload_completed check).
> Both patches fix our particular use cases and are regression free in
> aarch64-linux-gnu.
Did you also check for performance regressions?
Segher
This simply shows rs6000_modes_tieable_p is decidedly non-optimal:
it does not allow tying a scalar float to anything else. No such thing
is required, or good apparently. I wonder why we have such restrictions
at all in rs6000; is it just unfortunate history, was it good at one
point in time?
Segher
enforces it, makes sure we find it if the rules are broken.
Thanks and happy new year,
Segher
Hi!
On Fri, Dec 30, 2022 at 12:30:04AM -0800, Andrew Pinski wrote:
> On Thu, Dec 29, 2022 at 11:45 PM Segher Boessenkool
> wrote:
> > Ah! This simply shows rs6000_modes_tieable_p is decidedly non-optimal:
> > it does not allow tying a scalar float to anything else. No
ion to force the input and
> output modes to match for these instructions.
But things like popcount need to know the mode of the input, if it is
a negative constant anyway. Maybe we could simply disallow that?
Segher
if (TARGET_SAVE_TOC_INDIRECT && !cfun->calls_alloca)
> + if (TARGET_SAVE_TOC_INDIRECT
> + && !cfun->calls_alloca
> + && optimize_function_for_speed_p (cfun))
> cfun->machine->save_toc_in_prologue = true;
Is this correct? If so, it really needs a separate testcase.
The rest looks good. Thanks!
Segher
Hi!
On Wed, Jan 04, 2023 at 08:15:03PM +0800, Kewen.Lin wrote:
> on 2023/1/4 18:46, Segher Boessenkool wrote:
> >> @@ -25604,7 +25602,9 @@ rs6000_call_aix (rtx value, rtx func_desc, rtx
> >> tlsarg, rtx cookie)
> >>
> >> /* Can we optimize saving the
Hi!
Happy new year everyone.
Is this patch okay to commit?
Segher
---
htdocs/gcc-13/changes.html | 2 ++
1 file changed, 2 insertions(+)
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 3876ad77543a..954469cdcfa4 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs
On Thu, Jan 05, 2023 at 02:54:04PM -0500, Paul Koning wrote:
> > On Jan 5, 2023, at 2:27 PM, Segher Boessenkool
> > wrote:
> > +Support for old reload is deprecated. It will be removed in a
> > future
> > + release. Every target will always use LRA from t
Hi!
On Tue, Jan 10, 2023 at 09:26:13AM -0300, Adhemerval Zanella Netto wrote:
> On 12/12/22 20:52, Segher Boessenkool wrote:
> > On Mon, Dec 12, 2022 at 02:10:16PM -0300, Adhemerval Zanella Netto wrote:
> > How do you intend to modify all the existing copies of the header that
&
> + [(set_attr "type" "mtvsr")])
(Same issues here as above).
> +/* { dg-final { scan-assembler-times {\mmtvsrws\M} 1 { target {
> has_arch_ppc64 && has_arch_pwr9 } } } } */
mtvsrws does not need ppc64.
> +/* { dg-final { scan-assembler-times {\mmtvsrd\M} 1 { target {
> has_arch_ppc64 && has_arch_pwr9 } } } } */
> +/* { dg-final { scan-assembler-times {\mrldicr\M} 1 { target {
> has_arch_ppc64 && has_arch_pwr9 } } } } */
These two do of course.
> +/* { dg-final { scan-assembler-times {\mxscvspdpn\M} 2 { target {
> has_arch_pwr8 && has_arch_ppc64 } } } } */
But this doesn't.
Segher
On Tue, Jan 10, 2023 at 03:35:37PM +0100, Andreas Schwab wrote:
> On Jan 10 2023, Segher Boessenkool wrote:
>
> > The file starts with
> >
> > /* longlong.h -- definitions for mixed size 32/64 bit arithmetic.
> >Copyright (C) 1991-2022 Free Software Foundation
On Wed, Jan 11, 2023 at 03:34:45PM +0100, Richard Biener wrote:
> On Wed, Jan 11, 2023 at 3:22 PM Gerald Pfeifer wrote:
> >
> > On Thu, 5 Jan 2023, Segher Boessenkool wrote:
> > > Happy new year everyone.
> > >
> > > Is this patch okay to commi
On Wed, Jan 11, 2023 at 05:27:36PM +0100, Richard Biener wrote:
> > Am 11.01.2023 um 16:17 schrieb Segher Boessenkool
> > :
> >> Note this is more info for port maintainers not for users and
> >> changes.html is for users.
> >
> > And users will notice s
r the generic patches, but let me
update it to trunk first :-)
Segher
ipermail/gcc/2023-January/240497.html>?
I would say your predicates are way too lenient here (general_operand),
but this needs more info. A testcase to reproduce the problem, to
start with :-)
Segher
On Wed, Jan 11, 2023 at 05:07:47PM -0500, Paul Koning wrote:
> > On Jan 11, 2023, at 2:28 PM, Segher Boessenkool
> > wrote:
> > I would say your predicates are way too lenient here (general_operand),
> > but this needs more info. A testcase to reproduce the pr
On Thu, Jan 12, 2023 at 09:17:31AM -0500, Paul Koning wrote:
> > On Jan 12, 2023, at 4:50 AM, Segher Boessenkool
> > wrote:
> > I mean general_operand accepts that sp thing you saw. But your
> > constraints do not? (I don't know your target well, maybe this isn&#
Hi!
On Fri, Jan 13, 2023 at 07:05:34PM +0100, Jakub Jelinek wrote:
> On Mon, May 06, 2019 at 09:55:50PM +0000, Segher Boessenkool wrote:
> > We don't need this.
> >
> >
> > Segher
> >
> >
> > 2019-05-06 Segher B
is soon if no objections.
Looks okay. Some testcase stuff though:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr108348-1.c
> @@ -0,0 +1,23 @@
> +/* { dg-require-effective-target powerpc_p9modulo_ok } */
Please use a saner selector? If one doesn't exist yet, make a new one?
Something that just says "p9", not "modulo".
Thanks,
Segher
Hi!
On Mon, Jan 16, 2023 at 05:20:56PM +0800, Kewen.Lin wrote:
> on 2023/1/16 16:49, Segher Boessenkool wrote:
> >> +/* { dg-require-effective-target powerpc_p9modulo_ok } */
> >
> > Please use a saner selector? If one doesn't exist yet, make a new one?
> >
specifying -mcpu=power9, I didn't explicitly specify
> it before), I think I could use powerpc_altivec_ok to replace
> powerpc_p9modulo_ok here, does it sound good to you?
VMX can be turned off even with -mcpu=power9. So yes, it does need
powerpc_altivec_ok. Does it need VSX even?
Segher
; case OPT_Werror_:
> - if (lang_mask == CL_DRIVER)
> + if (ignore_w_error())
> + break;
> + if (lang_mask == CL_DRIVER)
> break;
The new indentation is messed up. And please don't move the existing
early-out to later, it make more sense earlier, the way it was.
Segher
On Thu, Sep 07, 2023 at 07:22:45AM -0400, Steven Rostedt wrote:
> On Thu, 7 Sep 2023 06:04:09 -0500
> Segher Boessenkool wrote:
> > On Thu, Sep 07, 2023 at 12:48:25PM +0300, Dan Carpenter via Gcc-patches
> > wrote:
> > No. You should patch your program, instead.
On Thu, Sep 07, 2023 at 02:23:00PM +0300, Dan Carpenter wrote:
> On Thu, Sep 07, 2023 at 06:04:09AM -0500, Segher Boessenkool wrote:
> > On Thu, Sep 07, 2023 at 12:48:25PM +0300, Dan Carpenter via Gcc-patches
> > wrote:
> > > I started to hunt
> > > down all the
mp;compare_code, &op0, &op1, 1);
> + }
> + else
> + {
> + if (dump_file && (dump_flags & TDF_DETAILS))
> + fprintf (dump_file, "CC register not used in comparison.\n");
"Where the CCmode register is used is not a comparison". But more
compact if you can manage (I cannot).
Segher
*/
> +/* { dg-final { scan-assembler-times {\mmodsw\M} 1 { xfail *-*-* } } } */
Thanks for the \m \M, it is much harder to determine if the tests
actually work, without that :-)
With improved changelog: okay for trunk. Okay for all backports as
well (after some soak time).
Thank you!
Segher
see an existing optab for andn.
For most RTL stuff we can deal with it just fine using existing
define_insn etc. stuff. I have no idea if any of this is harder in
Gimple?
> So OK from my side in case there are no negative comments or
> bikeshedding on the name. I can't approve the rs6000 changes
> though.
But I can :-) I'll reply to just that. Thanks for handling this!
Segher
al RTL name for it. That is fine, that is
what we do in many other places already. It is clear what is meant no
matter what :-)
Segher
for -mcpu=power11 support.
>
> In order to use -mcpu=power11, you will need to use a new enough binutils that
> supports the .machine power11 option.
This is a general thing: we always assume you have a binutils at least
as new as your GCC.
Segher
{powerpc}, @samp{powerpc64},
> -@samp{powerpc64le}, @samp{rs64}, and @samp{native}.
> +@samp{power9}, @samp{power10}, @samp{power11},
> +@samp{powerpc}, @samp{powerpc64}, @samp{powerpc64le},
> +@samp{rs64}, and @samp{native}.
Hint: you do not need to layout TeXinfo source code. TeX itself takes
care of that much better than you can. It is fine to keep some short
lines, this will be rewrapped in output anyway.
Okay for trunk with those changes. Also fine for backport to 14.
Thank you!
Segher
R10 and POWER11 processors.
The official names are Power10 and Power11 (only the P a capital).
Okay for trunk with that fixed. Also okay for backport to 14. (After
the usual burn-in period of course). Thanks!
Segher
-* } } */
> +/* Require VSX and Linux to eliminate systems where you can't do
> + __attribute__((__target_clones__(...))). */
All the same things here, mutatis mutandis.
Segher
On Thu, Jul 18, 2024 at 09:53:05AM -0500, Peter Bergner wrote:
> 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 } */
> >
> >
roblem after all, and giving the
user the same error message is the most helpful thing to do!
It can be useful to not say "ICE", but it already is prevented from
doing that here.
Segher
error messages you do not often know what caused the problem, so
just report on the facts you *do* know (and moreso with warnings, there
you typically only know something looks unusual).
Segher
ory operand"? Maybe even print out the actual
operand given, too.
Segher
Hi!
On Thu, May 16, 2024 at 02:56:49PM +0800, Jiufu Guo wrote:
> Jiufu Guo writes:
> > Segher Boessenkool writes:
> >> On Tue, May 14, 2024 at 05:53:56PM +0800, Jiufu Guo wrote:
> >>> Thanks so much for your great review!
> >>> Reference other messages
only? If there is a reason, document
that here (but is there a reason?)
> +/* { dg-require-effective-target ppc_float128_sw } */
> +/* { dg-require-effective-target powerpc_vsx_ok } */
> +/* { dg-options "-O2 -mdejagnu-cpu=power9 -mvsx -mabi=ieeelongdouble
> -Wno-psabi" } */
Same comments here: If you have a -mcpu you do not want vsx_ok or -mvsx.
Please fix these things and resend. Thanks!
Segher
1401 - 1500 of 6091 matches
Mail list logo
