On Fri, Oct 23, 2020 at 09:41:30AM +1030, Alan Modra wrote:
> On Thu, Oct 22, 2020 at 11:03:14AM -0500, Segher Boessenkool wrote:
> > On Thu, Oct 22, 2020 at 08:58:10AM -0700, Carl Love wrote:
> > > OK, looks like VSX_MM_SUFFIX doesn't exist anymore. Don't know what
On Sat, Oct 24, 2020 at 02:59:34PM +1030, Alan Modra wrote:
> On Fri, Oct 23, 2020 at 04:06:57PM -0500, Segher Boessenkool wrote:
> > On Fri, Oct 23, 2020 at 09:41:30AM +1030, Alan Modra wrote:
> > > On Thu, Oct 22, 2020 at 11:03:14AM -0500, Segher Boessenkool wrote:
> >
On Sun, Oct 25, 2020 at 11:55:39AM +1030, Alan Modra wrote:
> On Sat, Oct 24, 2020 at 12:31:43PM -0500, Segher Boessenkool wrote:
> > On Sat, Oct 24, 2020 at 02:59:34PM +1030, Alan Modra wrote:
> > > Those instructions aren't generated, we don't see them anywhere
sign_extend:DI (reg:SI r)) (const_int 2^n))
>
> instead of using a sign_extract.
Do we do that in simplify-rtx already (w/ the proper SUBREG_PROMOTED_*
stuff set)? If not, we should; if so, why does that not work here?
(Just the subreg->{sign,zero}_extend that is, nothing with the mult.)
Segher
Hi!
On Mon, Oct 26, 2020 at 10:09:41AM +, Alex Coplan wrote:
> On 22/10/2020 15:39, Segher Boessenkool wrote:
> > On Thu, Oct 15, 2020 at 09:59:24AM +0100, Alex Coplan wrote:
> > > Currently, make_extraction() identifies where we can emit an ASHIFT of
> > > an exten
ere yet, it is initialised just below to
> > MODE_PRECISION (mode).
>
> Yes, but bitsize isn't defined at all in this function AFAICT. Are
> comments not permitted to refer to variables defined immediately beneath
> them?
Of course you can -- comments are free form text after all -- but as
written it suggest there already is an initialised variable "modewidth".
Just move the initialisation to above this comment?
Segher
2 (ci) : ci;
Can you instead replace the mult by a shift somewhere earlier in
make_extract? That would make a lot more sense :-)
Segher
u=power10 -O2" } */
> -/* { dg-require-effective-target power10_ok } */
> +/* { dg-require-effective-target { int128 && power10_ok } } */
Or write it as two require statements, as we do most of the time?
Okay for trunk (with those tweaks if you want). Thanks!
Segher
th that fix or do you want me to?
>
> Sure, I can do that if you're pre-approving the patch.
> gcc.target/powerpc/pr93122.c too.
This is obvious and trivial, doesn't need approval (just send a mail
what you did). Thanks :-)
Segher
ed to clear all different VX bits
(one per cause), so 39-44, 53-55. To *set* it you need to pick which
one you want to set. Maybe this is all best left the the libc in use,
which should have its own policy for that, it might not be the same on
all libcs.
Segher
On Mon, Oct 26, 2020 at 01:28:42PM +, Alex Coplan wrote:
> On 26/10/2020 07:12, Segher Boessenkool wrote:
> > On Thu, Oct 15, 2020 at 09:59:24AM +0100, Alex Coplan wrote:
> > Can you instead replace the mult by a shift somewhere earlier in
> > make_extract? That would
+ if (shift_amt > 0 && len > (unsigned HOST_WIDE_INT)shift_amt)
Space after cast; better is to not need a cast at all (and you do not
need one, len is unsigned HOST_WIDE_INT already).
Segher
On Sun, Oct 25, 2020 at 05:16:10AM -0500, Segher Boessenkool wrote:
> On Sun, Oct 25, 2020 at 11:55:39AM +1030, Alan Modra wrote:
> > > If you use a macro that doesn't exist, the compiler simply does not
> > > build!
> >
> > My empirical evidence to the co
ltivec -mcmodel=large" } */
>
> /* The expansion for vector character multiply introduces a vperm operation.
Add a comment why we need lp64? (Easiest is if you use two separate
dg-require phrases.) With that, okay for trunk. Thanks!
Segher
but remove the unnecessary -mpcrel
> anyway.
>
> * gcc.target/powerpc/localentry-1.c: Remove -mpcrel from options.
> * gcc.target/powerpc/notoc-direct-1.c: Likewise.
> * gcc.target/powerpc/pr94740.c: Likewise.
Okay for trunk. Thanks!
Segher
d on the command line after the dg-options -mpowerpc64, and
That depends on your dejagnu version. (That is also why we have
-mdejagnu-cpu=, same reason).
> + common/config/rs6000/rs6000-common.c:rs6000_handle_option disables
> + -mpowerpc64 for -m32. */
Okay for trunk if you some words about dejagnu version. Thanks!
Segher
d be "index)\n");
Okay for trunk with that fixed as well. Thanks!
Segher
erpc/pr79439-2.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr79439-2.c
> @@ -1,5 +1,5 @@
> /* { dg-do compile { target { powerpc*-*-linux* && lp64 } } } */
(wow there are many)
Okay for trunk (with or without that extra cleanup). Thanks!
Segher
> Regstrapped powerpc64le-linux power10 and power8. OK?
Yes please. Thanks!
Segher
unk. Thanks!
Segher
ated to add a large constant. */
> +/* Test that PLI is generated to add a large constant. */
Nope, that is a bad idea. The test tested that we generate good code,
we should keep it that way.
Segher
On Tue, Oct 27, 2020 at 10:05:45AM +1030, Alan Modra wrote:
> aix64.opt is used for all rs6000-aix targets, linux64.opt for 64-bit
> and biarch powerpc linux targets. powerpc linux errors for -mcmodel
> when -m32 (yes, even when biarch Segher).
>From sysv4.h:
#ifndef RS6000_BI_A
if it does
not apply).
Segher
_MASK_ISA_LZCNT, 0,
CODE_FOR_lzcnt_hi, "__builtin_clzs", IX86_BUILTIN_CLZS, UNKNOWN, (int)
UINT16_FTYPE_UINT16)
A different thing altogether, my grep was a bit wide :-) But not a bug
anyway.
config/aarch64/aarch64.c: return val == mask * bitmask_imm_mul[__builtin_clz
(bits) - 26];
This seems bad as well, yes.
Thanks,
Segher
On Tue, Oct 27, 2020 at 10:35:59AM +, Alex Coplan wrote:
> On 26/10/2020 12:43, Segher Boessenkool wrote:
> > I do not like handling both mult and ashift in one case like this, it
> > complicates things for no good reason. Write it as two cases, and it
> > should
out?
Okay for trunk if so. Thanks!
Segher
On Tue, Oct 27, 2020 at 09:48:48PM +1030, Alan Modra wrote:
> On power10 these are "dg-do run" tests, so need -save-temps for the
> assembler scanning.
>
> Regression tested powerpc64le-linux power8 and power10. OK?
Yes please. Thanks!
Segher
> * gcc.target
SX is irrelevant.
Please fix those everywhere. Okay for trunk with that. Thanks!
Segher
nding mode into operand 0.
> +Operand 0 has mode @var{m}, which is scalar. This pattern is used to
> +implement the @code{fegetround} builtin function from the ISO C99
> +standard.
s/builtin //
For all those standard functions we have a __builtin_* variant as well,
so no need to mention it here I think.
> +@cindex @code{feraiseexcept@var{m}} instruction pattern
> +@item @samp{feclearexcept@var{m}}
> +@item @samp{feraiseexcept@var{m}}
> +Clears or raises the supported machine floating-point exceptions
> +represented by the bits in operand 1. Error status is stored as
> +nonzero value in operand 0. Both operands have mode @var{m}, which is
> +a scalar. This patterns are used to implement the
"These patterns"
With those tweaks, the rs6000 part of the patch is okay for trunk.
Thanks! (The generic part looks fine to me as well, but I am not
maintainer of that.)
Segher
der dejagnu, or should I
> try to explicitly check for this in the future?
I don't know what version of dejagnu introduced the fix, but probably
newer than our minimum required version.
Thanks,
Segher
runcate-longlong.c: Likewise.
> * gcc.target/powerpc/vsx-store-element-truncate-short.c: Likewise.
> * gcc.target/powerpc/altivec-consts.c: Likewise, add -save-temps.
> * gcc.target/powerpc/le-altivec-consts.c: Likewise.
Okay for trunk. Thanks!
Segher
patch is strictly an improvement already, it is okay for
trunk (if the 2nd works on powerpc64le-linux of course ;-) ) Thanks!
(Improving it to test on exactly the right targets would be nice :-) )
Segher
ODE (inner) == TRUNCATE
> /* If trying or potentionally trying to extract
> bits outside of is_mode, don't look through
Okay for trunk like that. Thanks!
Segher
| RS6000_BTC_BINARY), \
CODE_FOR_ ## ICODE) /* ICODE */
(so just HARD_FLOAT and FLOAT128 are needed)
What am I missing?
Segher
ne
the existing ones with TFmode as well (if that is the same as KFmode)?
Segher
nt purpose, since it is not a standard mode.
(Some libgcc maintainer needs to approve the generic parts, not all of
it can obviously only trigger for us.)
Segher
Hi David, all,
On Thu, Oct 29, 2020 at 10:12:31AM -0400, David Edelsohn wrote:
> > I'm sorry you see this as a matter of respect. I didn't see it that
> > way at all. Segher disagreed with your review, and gave sufficient
> > technical reason for me to commit th
Hi!
On Thu, Oct 29, 2020 at 12:45:15PM -0400, Michael Meissner wrote:
> On Wed, Oct 28, 2020 at 07:04:31PM -0500, Segher Boessenkool wrote:
> > > +#if HAVE_KF_MODE
> > > + strfromf128 (buf, BUFMAX, BFP_FMT, (BFP_VIA_TYPE) x);
> > > +#else
> > >
calar_insert_exp_tff")?
>
> That is the existing function in the library. All I'm doing is adding TF
> versions of the existing functions.
Sure, but logically the macro for scalar_insert_exp_tfp would be VSIETFP
(instead of VSIETF) (and that is a new macro name fwiw). So please fix
that?
Segher
On Thu, Oct 29, 2020 at 12:50:10PM -0400, Michael Meissner wrote:
> On Wed, Oct 28, 2020 at 06:27:42PM -0500, Segher Boessenkool wrote:
> > On Thu, Oct 22, 2020 at 06:09:38PM -0400, Michael Meissner wrote:
> > > This patch adds long double variants of the power10 _
On Thu, Oct 29, 2020 at 12:56:03PM -0400, Michael Meissner wrote:
> On Wed, Oct 28, 2020 at 04:58:46PM -0500, Segher Boessenkool wrote:
> > > #if defined (__LONG_DOUBLE_128__) && defined (__LONG_DOUBLE_IBM128__)
> > > \
> > > && !
On Thu, Oct 29, 2020 at 01:03:25PM -0400, Michael Meissner wrote:
> On Tue, Oct 27, 2020 at 06:27:22PM -0500, Segher Boessenkool wrote:
> > > +/* { dg-do compile { target { powerpc*-*-linux* } } } */
> >
> > Use *-*-linux* instead? (In all relevant tests.)
>
>
ut simply "making ROP attacks less likely to succeed" -- it is almost
always a binary thing, either it succeeds or it doesn't).
Segher
On Thu, Oct 29, 2020 at 06:31:54PM +, Joseph Myers wrote:
> On Thu, 29 Oct 2020, Segher Boessenkool wrote:
> > On Thu, Oct 29, 2020 at 12:45:15PM -0400, Michael Meissner wrote:
> > > On Wed, Oct 28, 2020 at 07:04:31PM -0500, Segher Boessenkool wrote:
> >
XX ())
> > > > + || ((TARGET_GLIBC_MAJOR * 1000) + TARGET_GLIBC_MINOR)
> > > > < 2032))
> > > > {
> > > > - warned_change_long_double = true;
> > >
> > > Does this need to be added back elsewhere?
> >
> > At the present time, we are not contemplating adding the full support
> > to enable
> > configuring GCC to use IEEE 128-bit long double in GCC 10 or
> > earlier. This may
> > change depending on customer demands.
> >
>
> My question was/is specific with the removal of the assignment
>
> - warned_change_long_double = true;
>
> I didn't see where that line or an equvalent was added back. It's
> either set elsewhere (ok), or no longer used.
It isn't set anywhere else.
Mike, the patch is okay for trunk with that line restored. Thanks!
(And thanks for spotting the problem Will!)
Segher
On Thu, Oct 29, 2020 at 09:09:13AM +1030, Alan Modra wrote:
> On Wed, Oct 28, 2020 at 12:16:00PM -0500, Segher Boessenkool wrote:
> > On Wed, Oct 28, 2020 at 09:20:56PM +1030, Alan Modra wrote:
> > > Otherwise some versions of dejagnu go ahead and run the vsx tests
> > >
Hi!
On Fri, Oct 30, 2020 at 09:36:13AM -0700, Carl Love wrote:
> On Wed, 2020-10-28 at 20:43 -0400, David Edelsohn wrote:
> > Better, but please use
> >
> > /* { dg-require-effective-target int128 } */
> >
> > not "target int128" in the selector. Se
&& !BYTES_BIG_ENDIAN
> + && DEFAULT_ABI == ABI_ELFv2
> + && ((TARGET_GLIBC_MAJOR * 1000) + TARGET_GLIBC_MINOR) >= 2032)
> +return true;
> +#endif /* GLIBC provided. */
> +
> + return false;
> +}
> +
So this makes the compiler behave differently based on what the libc
used at build time was (including its version). Can't we do better? :-(
Segher
On Fri, Oct 30, 2020 at 04:00:30PM -0400, Michael Meissner wrote:
> On Fri, Oct 30, 2020 at 01:52:13PM -0500, Segher Boessenkool wrote:
> > On Fri, Oct 30, 2020 at 01:21:34PM -0400, Michael Meissner wrote:
> > > David reminded me that not all targets support GLIBC. This patch sh
VEXTRACTUB"
>"#"
You add * to both alternatives here? I would expect adding it to only
the second alternative, does it work better with both?
That also avoids a different problem: * won't work as expected.
'*' in IRA skips one constraint character, but can be "wa", a
two-letter constraint (and we do have an "a" constraint as well,
something wholly different: "wa" means a VSX register, while "a" is an
indexed address).
case '*':
/* Ignore the next letter for this pass. */
c = *++p;
break;
Segher
On Fri, Oct 30, 2020 at 06:50:30PM -0400, Michael Meissner wrote:
> On Fri, Oct 30, 2020 at 03:54:06PM -0500, Segher Boessenkool wrote:
> > But, time will fix all problems here. So, okay for trunk. Thanks!
>
> Note, I discovered the ABI is not set to ELFv2 at the time the test
> +return (a < b ? 0 : (a > b ? 2 : 1));
> > +}
Please add a comment what this test wants to test for? Something like
/* If-conversion should . */
maybe?
I would approve this patch, given that the compiler will immediately ICE
if something not a zero is passed as operands[3] (although it would be
nice to have a zero_int_operand that would aonly allow const_int).
David, do you agree given all of the above?
Thanks,
Segher
On Wed, Nov 16, 2022 at 06:06:19AM -0600, Segher Boessenkool wrote:
> Hi guys,
>
> On Tue, Nov 15, 2022 at 10:04:04PM -0500, David Edelsohn wrote:
> > On Tue, Nov 15, 2022 at 9:32 PM HAO CHEN GUI wrote:
> > > The patch enables have_cbrnachcc4 which is a flag in ifcvt
d that shows things still
generate the same code?
Segher
only marginally related things, at every step. Or I don't
see it anyway :-)
Segher
avoid an ICE or other
bug. Isn't REE *always* a good thing, it never degrades code quality?
Or are there situations where it results in worse code?
Segher
Hi!
Please look at
<https://inbox.sourceware.org/gcc-patches/20230419200011.gg19...@gate.crashing.org/>
and reply to that message, with answers to the questions? And make sure
you are listed in MAINTAINERS before anything else. Thanks!
Segher
one can accidentally commit it :-)
I thought about Cc:ing lots and lots of people, should I do that?
Segher
---
gcc/config/alpha/alpha.cc | 3 ---
gcc/config/arc/arc.cc | 2 --
gcc/config/avr/avr.cc | 3 ---
gcc/config/bfin/bfin.cc | 3 ---
g
Hi!
On Sun, Apr 23, 2023 at 02:36:05PM -0400, Paul Koning wrote:
> > On Apr 23, 2023, at 12:47 PM, Segher Boessenkool
> > wrote:
> > 1) Targets that already always have LRA, but that redefine the hook
> > anyway. These are gcn, pdp11, rx, sparc, vax, and xtensa. Nothin
(You didn't leave me in Cc: on the reply. Maybe you did a
reply-to-only-one-person?)
On Sun, Apr 23, 2023 at 11:01:05AM -0600, Jeff Law via Gcc-patches wrote:
> On 4/23/23 10:47, Segher Boessenkool wrote:
> >3) Targets that as of yet never used LRA. Many of those will be fin
On Sun, Apr 23, 2023 at 07:56:56PM +0100, Maciej W. Rozycki wrote:
> On Sun, 23 Apr 2023, Segher Boessenkool wrote:
> > 1) Targets that already always have LRA, but that redefine the hook
> > anyway. These are gcn, pdp11, rx, sparc, vax, and xtensa. Nothing
> > really chan
An old patch to enable Alpha is at
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66207
Ah, good to hear it worked way back then already!
We still need someone to test this on alpha now, years later, and give
a final okay, but hearing this is encouraging :-)
Segher
On Mon, Apr 24, 2023 at 10:19:23AM +0200, Richard Biener wrote:
> On Sun, Apr 23, 2023 at 6:48 PM Segher Boessenkool
> wrote:
> >
> > This minimal patch enables LRA for all targets. It does not clean up
> > the target code, nor does it do anything to generic code: it jus
VECTOR_UNIT_ALTIVEC_OR_VSX_P with VECTOR_MEM_ALTIVEC_OR_VSX_P.
> * config/rs6000/predicates.md (const_vector_each_byte_same): New
> predicate.
Okay for trunk. Let's backport this to 13 once 13.1 has been released,
this patch is not very trivial so there is some risk.
Thanks!
Segher
ires for -m32 -mpowerpc64 that the mask is
> + <= 0x7ff. */
> + return (UINTVAL (mask) << (63 - nb)) <= 0x7fff;
> +}
> + else
> +return false;
No superfluous "else" please, just put a blank line there.
Okay for trunk (with Ke Wen's remarks fixed, but you already did :-) )
Thanks!
Segher
Hi!
On Mon, Apr 24, 2023 at 11:46:50AM +0200, Uros Bizjak wrote:
> On Mon, Apr 24, 2023 at 11:19 AM Segher Boessenkool
> wrote:
> > We still need someone to test this on alpha now, years later, and give
> > a final okay, but hearing this is encouraging :-)
>
> Please no
d. Just not something that makes the less
important of the (so far) two testcases look more important than it is.
The testcases are fine otherwise, thanks!
Segher
rn b;
> +}
> +
> +/* { dg-final { scan-assembler-not "rlwinm" } } */
Please at least use {\mrlwinm\M}. There are many other insns that can
be used for this same purpose as well. We should at least test rldicl
here as well.
Segher
tion is seen in PR
> middle-end/35860.
But what causes the problem? Is something missing somewhere, or do we
get too high register pressure?
There also is -fsplit-wide-types-early, which might help.
In principle it always is good to describe a machine model as close as
possible to what the machine actually does. What gets in the way here?
Segher
esumably wants those to be used preferably.
The patch did not change the default because that always is a lot of
pain. The cost-benefit analysis did not work out here (for me!)
Segher
Hi!
On Tue, May 02, 2023 at 05:20:49PM +0100, Roger Sayle wrote:
> On 02 May 2023 14:49, Segher Boessenkool wrote:
> Then combine inserts an additional copy:
Combine makes sure a pseudo-to-pseudo move remains. Without that,
combine will seize part of RA's job, and butcher it. It
t; +/* { dg-require-effective-target lp64 } */
> +/* { dg-require-effective-target power10_ok } */
> +/* { dg-require-effective-target powerpc_prefixed_addr } */
> +/* { dg-options "-O2 -mdejagnu-cpu=power10 -fstack-protector" } */
The power10_ok selector still is terribly broken (it allows only some
variants of 64-bit Linux and nothing more, to start with). Do we still
need it in any case?
Same for powerpc_prefixed_addr. Is there any supported target that does
not have a working assembler?
What is -fstack-protector here for? That should be documented, or
better, it should just be removed if possible.
> -/* { dg-final { scan-assembler-times "lwa_cmpdi_cr0_SI_clobber_CC_none"
> 4 { target lp64 } } } */
> +/* { dg-final { scan-assembler-times "lwa_cmpdi_cr0_SI_clobber_CC_none"
> 8 { target lp64 } } } */
> -/* { dg-final { scan-assembler-times "lwa_cmpdi_cr0_SI_clobber_CC_none"
> 9 { target ilp32 } } } */
> +/* { dg-final { scan-assembler-times "lwa_cmpdi_cr0_SI_clobber_CC_none"
> 16 { target ilp32 } } } */
Why are these new counts correct?
Segher
then work
> the maintainers of the CCP to fix the problem.
Erm. If the compiler ICEs, we can not include this code. But hopefully
you mean something else?
Segher
On Fri, Jan 20, 2023 at 04:05:58PM -0500, Michael Meissner wrote:
> Ping patch. We really would like the patches to enable the possible future
> MMA+ instructions into GCC 13.
Please send a version with Peter's comments taken into account?
Segher
7 bits. It sounds like that is what you hit,
with some -O0 build perhaps. But either way UB is UB, the program has
no meaning, any output is correct, no output is correct as well :-)
Nasal demons and all that.
bootstrap-ubsan should have found this?
Segher
On Thu, Feb 09, 2023 at 10:15:22AM +0800, Xionghu Luo wrote:
> Thanks Kewen!
> Ping this again @Segher.
> Maybe we could also merge this patch if no objections from Segher as
> several reviews and tests taken on this already...
Please send the patch as the head of its own thread, no
fer_range_manager
>
> various APIs/comments with the term "side effect" renamed to "infer
> range" or some variation of tense.
Thank you!
Segher
We'll get used
to it (if those long lines are fixed ;-) )
> Nit: Some of these BTM lines below exceed 80 characters, a few already existed
> previously.
Yes, and it is easily avoidable in this case. Most of these comments
have no content at all, and the rest could just be on separate lines.
But, are those builtin masks still used at all? Can't we just use the
option masks where they still are? The builtins do not use them
anymore :-)
Segher
On Thu, May 26, 2022 at 09:16:59AM -0400, David Edelsohn wrote:
> Does Power10 fully support int128 in 32 bit mode? I would expect no,
> so the additional test is required.
It isn't supported on any 32-bit ABI, Power or not. It would simplify
many things if it was though!
Segher
On Thu, May 26, 2022 at 09:40:18AM -0500, will schmidt wrote:
> On Thu, 2022-05-26 at 05:47 -0500, Segher Boessenkool wrote:
> > Yeah, the longer names are a bit annoying in any case. We'll get
> > used
> > to it (if those long lines are fixed ;-) )
>
> Agree. I
p_two:GPR (match_operand:CCFP 1 "cc_reg_operand" "y")
> > (const_int 0)))]
> > - "!flag_finite_math_only"
> > + ""
> >"#"
> > - "&& 1"
> > + ""
>
> Segher added
)
(unspec:SFDF [(match_operand:SFDF 1 "vsx_register_operand" "wa")
(match_operand:SFDF 2 "vsx_register_operand" "wa")]
FMINMAX))]
"TARGET_VSX"
"xsdp %x0,%x1,%x2"
[(set_attr "type" "fp")])
(FMINMAX has the same indent as the preceding [, its sibling;
"TARGET_VSX" and the next two lines are indented like the same thing
before it at the same level (the "[(set"); the finishing ) does never
start a new line).
Segher
Hi!
On Tue, May 31, 2022 at 06:56:00PM -0500, Segher Boessenkool wrote:
> It's not clear to me how this can ever happen without finite_math_only?
> The patch is safe, sure, but it may the real problem is elsewhere.
So, it is incorrect the RTL for our bcd{add,sub} insns uses CCFP at
Hi!
On Thu, Jun 02, 2022 at 01:30:04PM +0800, HAO CHEN GUI wrote:
> Segher,
> Does BCD comparison return false when either operand is invalid coding?
It sets all of LT, GT, and EQ to 0 (it normally sets exactly one of them
to 1). It sets bit 3 (the "SO" bit usually) to 1.
On Thu, Jun 02, 2022 at 03:06:52PM -0400, Michael Meissner wrote:
> Ping patch posted on May 13th:
Are you not going to apply any of Will's suggestions? They looked solid
to me.
Segher
On Fri, Jun 03, 2022 at 01:44:30PM -0400, Michael Meissner wrote:
> On Thu, Jun 02, 2022 at 04:30:19PM -0500, Segher Boessenkool wrote:
> > On Thu, Jun 02, 2022 at 03:06:52PM -0400, Michael Meissner wrote:
> > > Ping patch posted on May 13th:
> >
> > Are you no
@@ -0,0 +1,14 @@
> +/* { dg-do compile { target lp64 } } */
> +/* { dg-options "-mdejagnu-cpu=power6 -O2" } */
It doesn't require -m64, only -mpowerpc64. You can use has_arch_ppc64
to test for the latter.
Okay for trunk, even without that improvement. Thanks!
Segher
stuff like this, it is easy to accidentally get
the conditions on a define_* and one of its uses out of synch. But it
looks to be okay in this case :-)
Segher
is a totally boring number of print statements after
all), and you can pull it from git history anyway.
Segher
t;DI")
>(V4SF "SF")
>(V4SI "SI")
> (V8HI "HI")
>(V16QI "QI")])
Yeah, the comment
;; Map the scalar mode for a vector type
is misleading, in more ways than one :-(
And the whole thing is just the same as VEC_base anyway, so it is much
better to just use that.
Segher
Hi!
On Tue, Jun 07, 2022 at 09:51:43AM +0800, HAO CHEN GUI wrote:
> On 2/6/2022 上午 5:01, Segher Boessenkool wrote:
> > On Wed, May 18, 2022 at 04:52:26PM +0800, HAO CHEN GUI wrote:
> >>const double __builtin_vsx_xsmaxdp (double, double);
> >> -XSMAXDP smaxdf3 {
ing to add a flag to those cpus rs6000-cpu.def entries.
The p10 cpu support should simply not enable the option by default.
There is no reason to play games.
Segher
fast-math (because
the new unspecs arent't optimised like standard rtl is). This can be
follow-up work of course -- and the best direction is to make fmin/fmax
generic, even! :-)
Segher
On Thu, Jun 09, 2022 at 09:24:00AM +0800, HAO CHEN GUI wrote:
> On 8/6/2022 下午 9:24, Segher Boessenkool wrote:
> > But it regresses the code quality generated with -ffast-math (because
> > the new unspecs arent't optimised like standard rtl is). This can be
> > follow-up
FP_ISA3 is exactly the same as SFDF, just a less obvious name. So,
let's delete it.
Tested, committed, the works.
Segher
2022-06-09 Segher Boessenkool
* config/rs6000/rs6000.md (FP_ISA3): Delete.
(float2): Rename to...
(float2): ... this. A
s a good idea to add a comment a la
/* PR rtl-optimization/105041: This test failed with -m32. */
Thanks again for the patch!
Segher
ad paired should be disabled as well, for the same reason. The patch
seems to do that fine? Please fix the commit message.
Thanks,
Segher
> 2022-06-09 Michael Meissner
>
> gcc/
> * config/rs6000/rs6000.cc (rs6000_option_override_internal): Do
> not generate block
On Tue, Jun 14, 2022 at 03:57:08PM +0800, Kewen.Lin wrote:
> PR target/105818
Change this to something else? It is not a target bug. "middle-end"
perhaps?
Thanks for fixing this,
Segher
that "pld$" will match of course).
So no doubt this will improve things, but we need testing of each part
separately. Also look at code size, or differences in the generated
code in general: this is much more sensitive to detect than performance,
and is not itself sensitive to things like system load, so a) is easier
to measure, and b) has more useful outputs, outputs that tell more of
the whole story.
Segher
Hi!
On Wed, Jun 15, 2022 at 04:19:41PM +0800, Jiufu Guo wrote:
> Segher Boessenkool writes:
> > Have you tried with different limits?
> I drafted cases(C code, and updated asm code) to test runtime costs for
> different code sequences: building constants with 5 insns; with 3
>
2501 - 2600 of 6091 matches
Mail list logo
