, pgs, pge, pmz, ptc, pdn,
> ptn, pdd, prc, pi, pbm, pel, trt): Make use of $arg0 if a user passed
> it
(Lines in a changelog end in a dot).
I love this... if it works :-) How was it tested? With what GDB versions?
Segher
port for it, we'd want this test to run
for it).
> +/* { dg-final { scan-assembler-times "std " 0 } } */
We usually write this as scan-assembler-not, but this works just fine
as well. Whichever you prefer.
Segher
fferent type.
>
> Spot-tested on powerpc64-linux-gnu. OK to install?
That looks fine, thanks! Yes please, okay for trunk, and for backports
as needed or wanted.
Segher
> 2019-11-15 Richard Sandiford
>
> gcc/
> PR target/92515
> * config/rs6000/rs6000-call.c
if you did
something like
case "$target" in
powerpc*-*-linux-musl)
gcc_cv_target_ldbl128=no
;;
s390*-*-linux-musl)
gcc_cv_target_ldbl128=yes
;;
powerpc*-*-linux* |
sparc*-*-linux* |
s390*-*-linux* |
alpha*-*-linux*)
AC_ARG_WITH(long-double-128,
etc., i.e. add the musl targets to the main switch here?
Segher
On Fri, Nov 15, 2019 at 06:03:25PM +, Szabolcs Nagy wrote:
> On 15/11/2019 17:48, Segher Boessenkool wrote:
> > I think it would be much more readable and maintainable if you did
> > something like
> >
> > case "$target" in
> > powerpc*-*-l
*, and it doesn't do anything for
other *-musl* configurations.
The powerpc part is okay for trunk, if this is what musl wants to do.
(musl has no OS port maintainer listed in MAINTAINERS, maybe that should
be fixed?)
Segher
I missed this part in r266961. Various people have been editing it
since; I finally noticed.
Committed.
2019-11-16 Segher Boessenkool
* common/config/powerpcspe: Delete.
Instead, make the second arm copy from the dest of the first set. Most
of the time this copy will be optimized away later.
I am still testing this across many archs; will commit later if that
works out well.
Segher
2019-11-16 Segher Boessenkool
* combine.c (try_combine): If we
Also make it a parmeterized name: @cceq_{ior,rev}_compare_.
Committing to trunk.
Segher
2019-11-16 Segher Boessenkool
* config/rs6000/rs6000.md (cceq_ior_compare): Rename to...
(@cceq_ior_compare_ for GPR): ... this. Allow GPR instead of
just SI
On Tue, Nov 12, 2019 at 09:52:43PM +, Segher Boessenkool wrote:
> C++98 does not have long long int, and does not use (unsigned) long
> long int for hexadecimal literals. So let's use an ULL suffix here,
> which is still not strict C++98, but which works with more compilers.
&
this is a valid thing to do -- the asm semantics are still satisfied,
> and asm volatile ("" : : : "memory") never acted as a register barrier.
> But perhaps we should deal with this as a special case?
I don't think we should, no. What does "register barrier" even mean,
*exactly*?
(I'll look at the new version of your patch, but not today).
Segher
e doesn't get too high.
I don't see why it wouldn't work? If you apply it now we will still
have a lot of time to find problems with it, if those exist.
The combine parts are okay for trunk, if you keep an eye out :-)
Segher
it is pretty hard to check if the changes to the
power6 code are correct. I'll just trust you got it right, the power9
part looks fine, so okay for trunk. Thanks!
Segher
> 2019-11-18 Pat Haugen
>
> * config/rs6000/rs6000.c (move_to_end_of_ready): New, factored out
>
e...
Sounds perfectly fine to me, but how many tests will need changing? Is
it only those that use symbol versioning directly?
Segher
registers, does it? It isn't
documented like that, in any case.
(Of course it is somewhat silly to return a mode that cannot be used, and
it is likely the target can do better.)
Segher
revert the patch? I'll re-implement the simplify-rtx
part of it properly, if you want. And I can test the CSE part separately.
But right now we need trunk to work again.
Thanks,
Segher
ou will get less
> friendly error message from assembler. I hope that is acceptale since
> we have pre-existing situations like that already.
Ah, I thought this would happen for various things from libc as well, so
there would be a lot of random fallout. I probably misunderstood :-)
Segher
On Tue, Nov 19, 2019 at 04:32:09PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > r278411 causes bootstrap to fail on at least all powerpc*. Also, I am
> > author of this simplify-rtx code, and I think what you did is all wrong.
> > Also, it should be two
break;
default:
gcc_unreachable ();
}
rtx comp1 = gen_rtx_fmt_ee (cond, mode, operands[1], operands[2]);
rtx res1 = gen_reg_rtx (mode);
emit_insn (gen_rtx_SET (res1, comp1));
rtx comp2 = gen_rtx_fmt_ee (cond, mode, operands[2], operands[1]);
rtx res2 = gen_reg_rtx (mode);
emit_insn (gen_rtx_SET (res2, comp2));
if (need_invert)
{
rtx comp3 = gen_rtx_fmt_ee (IOR, mode, res1, res2);
rtx comp4 = gen_rtx_fmt_e (NOT, mode, comp3);
emit_insn (gen_rtx_SET (operands[0], comp4));
}
else
emit_insn (gen_ior3 (operands[0], res1, res2));
})
(the result of a split does not get combine etc. optimisations anymore,
so you have to generate pretty much ideal code directly).
HTH, sorry for the late reply,
Segher
s not update dominators.
Yeah. Of course this only does anything if the targeted block is only
a return insn (and maybe a USE of the return value), so nothing bad will
happen, but the dom info is not technically correct anymore.
Segher
Hi!
On Mon, Nov 18, 2019 at 04:21:07PM +0800, luoxhu wrote:
> On 2019/11/15 18:17, Segher Boessenkool wrote:
> > On Thu, Nov 14, 2019 at 09:12:32PM -0600, Xiong Hu Luo wrote:
> >> P9LE generated instruction is not worse than P8LE.
> >> mtvsrdd;xxlnot;stxv vs. not;not;st
On Tue, Nov 19, 2019 at 11:33:13AM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Sun, Nov 17, 2019 at 11:35:26PM +, Richard Sandiford wrote:
> >> While working on SVE, I've noticed several cases in which we fail
> >> to combine instru
Hi Richard,
On Tue, Nov 19, 2019 at 07:35:10PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > r278411 causes bootstrap to fail on at least all powerpc*. Also, I am
> > author of this simplify-rtx code, and I think what you did is all wrong.
> > Also, it
This is the analogue of r278103, but for DFP.
Committing to trunk.
Segher
2019-11-20 Segher Boessenkool
PR target/92573
* config/rs6000/dfp.md (dfptstsfi__ for DFP_TEST and DDTD):
Handle UNORDERED if !HONOR_NANS.
---
gcc/config/rs6000/dfp.md | 6 ++
1 file
res1);
rtx not2 = gen_rtx_fmt_e (NOT, mode, res2);
rtx comp3 = gen_rtx_fmt_ee (AND, mode, not1, not2);
emit_insn (gen_rtx_SET (operands[0], comp3));
> diff --git a/gcc/config/rs6000/vector.md b/gcc/config/rs6000/vector.md
> index b132037..deeab9f 100644
> --- a/gcc/config/rs6000/vector.md
> +++ b/gcc/config/rs6000/vector.md
> @@ -107,6 +107,12 @@
>(smin "smin")
>(smax "smax")])
>
> +;; code iterators and attributes for vector FP comparison operators:
> +(define_code_iterator
> + vector_fp_comparison_operator [lt le ne ungt unge unlt unle])
Can you change this name so it is clear it is just the simple ones?
Segher
Hi!
On Wed, Nov 20, 2019 at 09:42:46AM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> >> Before I resubmit, why is the simplify-rtx.c part all wrong?
> >
> > It was nice and simple, and it isn't anymore. 8 4 2 1 for the four of
> > lt gt eq
On Wed, Nov 20, 2019 at 03:46:29PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > UNLT & ORDERED is always LT. When would it not be true?
>
> LT traps on quiet NaNs for -ftrapping-math, UNLT and ORDERED don't.
No? -ftrapping-math makes nothing trap.
On Wed, Nov 20, 2019 at 05:30:48PM +0100, Jakub Jelinek wrote:
> On Wed, Nov 20, 2019 at 10:17:38AM -0600, Segher Boessenkool wrote:
> > On Wed, Nov 20, 2019 at 03:46:29PM +, Richard Sandiford wrote:
> > > Segher Boessenkool writes:
> > > > UNLT & ORDERED i
code = unsigned_condition (code);
>
> Or I can add signed_comparison_p and unsigned_comparison_p functions
> that take codes instead of rtxes.
That may be easier, dunno.
Thanks,
Segher
On Wed, Nov 20, 2019 at 04:59:49PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Wed, Nov 20, 2019 at 05:30:48PM +0100, Jakub Jelinek wrote:
> >> On Wed, Nov 20, 2019 at 10:17:38AM -0600, Segher Boessenkool wrote:
> >> > On Wed, Nov 20, 201
On Wed, Nov 20, 2019 at 06:20:34PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > So this would work if you had pseudos here, instead of the hard reg?
> > Because it is a hard reg it is the same number in both places, making it
> > hard to move.
>
&g
16:
Coming from gimple this is
_5 = a_3(D) u<= b_4(D);
_7 = ~_5;
_8 = a_3(D) unord b_4(D);
_9 = _7 | _8;
if (_9 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
which could use some improvement.
Anyway, testing on p8le and p9le as well; will commit if that works fine.
Segher
On Wed, Nov 20, 2019 at 11:17:11PM +, Segher Boessenkool wrote:
> We currently expand various floating point comparisons early, to some
> sequences with cror insns and the like. This doesn't optimize well.
>
> Change that to allow any of the 14 floating point comparisons in
{ scan-assembler-not "lxvd2x" } } */
> -/* { dg-final { scan-assembler-not "stxvd2x" } } */
> -/* { dg-final { scan-assembler-not "xxpermdi" } } */
> /* { dg-final { scan-assembler-not "mfvsrd" } } */
> /* { dg-final { scan-assembler-not "mfvsrd" } } */
So, for all targets, the read case should be ld;ld;not;not. And for
p9+ the write case should be mtvsrdd;xxlnor;stxv while for pre-p9 it
should be not;not;std;std.
Could you write it like that? And then add xfails where we currently
fail, maybe?
> +# Return 1 if we're generating code for post-power9 platforms.
> +# Power9 is included.
> +
> +proc check_effective_target_post_power9 { } {
> + return [check_no_compiler_messages_nocache post_power9 assembly {
> + #if !(defined(_ARCH_PWR9))
> + #error NO
> + #endif
> + } ""]
> +}
The code for these tests is fine btw, it's just the names that I'm not
sure about.
Segher
On Thu, Nov 21, 2019 at 02:36:53PM +0100, Bernd Schmidt wrote:
> On 11/13/19 5:16 PM, Segher Boessenkool wrote:
> > On Wed, Nov 13, 2019 at 02:13:48PM +0100, Bernd Schmidt wrote:
> >> Also, it does not compute costs for jump
> >> insns, so they are always set to
ry for going
back on this -- I have said that before haven't I?)
> + switch (cond)
> +{
> +case LTGT:
> + cond = GT;
> + break;
> +case ORDERED:
> + cond = GE;
> + break;
> +default:
> + gcc_unreachable ();
> +}
It feels a bit lighter (and is shorter) if you write
if (cond == LTGT)
cond = GT;
else if (cond == ORDERED)
cond = GE;
else
gcc_unreachable ();
Okay for trunk with those trivialities taken care of one way or the
other. Thanks!
Segher
s" is where it really should combine
with just 3 of them, but something prevents that, often cost, while
throwing in a 4th insn tilts the balance just enough. We used to have
a lot of that with 3-insn combinations as well, and probably still have
some.
Segher
On Thu, Nov 21, 2019 at 08:32:14PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > It's not great if every pass invents its own version of some common
> > infrastructure thing because that common one is not suitable.
> >
> > I.e., can this be fixe
On Thu, Nov 21, 2019 at 08:12:05PM -0500, Paul Koning wrote:
> > On Nov 21, 2019, at 7:42 PM, Segher Boessenkool
> > wrote:
> >
> > ...
> > Maybe i386 should implement the insn_cost hook as well? For most targets
> > that is a lot simpler to get right t
fined(_ARCH_PWR9))
> + #error NO
> + #endif
> + } ""]
> +}
Maybe it is useful to have even shorter names, p9+, since room is scarce
where it is used (just like le and be). But maybe it doesn't matter?
Segher
ter would not be used for
> things
> +; that be loaded with PLI.
That comment doesn't add much at all? This splitter isn't used for
constants we can load in one insn, that's right. That happily works
just fine if we have prefixed insns as well.
Okay for trunk with those things fixed. Thanks!
Segher
000) >= 0x1
> - && (INTVAL (operands[1]) & 0x) != 0"
> + && (INTVAL (operands[1]) & 0x) != 0 && !TARGET_PREFIXED_ADDR"
>[(set (match_dup 0)
> (match_dup 2))
> (set (match_dup 0)
Please use num_insns_constant, instead (and fix num_insns_constant_gpr
so it knows about SIGNED_34BIT).
Segher
,
VEC_F). Erm.
Wait, this is called *add3, not add3.
Okay for trunk with that fixed. Thanks,
Segher
ic instructions, it certainly shouldn't print commas and other
fields.
Can you fix this in the caller?
Segher
relative addressing when -mcpu=future is used to pass this test.
> +
> +proc check_effective_target_powerpc_pcrel_ok { } {
> +if { ([istarget powerpc*-*-*]) } {
> + return [check_no_compiler_messages powerpc_pcrel_ok object {
> + int main (void) {
> + static int s __attribute__((__used__));
> + int e;
> + asm ("plwa %0,s@pcrel(0),1" : "=r" (e));
> + return e;
> + }
> + } "-mfuture"]
> + } else {
> + return 0
> + }
> +}
So every assembler will support either all three of these, or none.
Can you simplify this please?
Segher
7;t get better.
My powerpc64 config actually built the powerpc64le config, since the
kernel since a while looks what the host system is, for its defconfig.
Oh well, fixed now.
There are fivew new failures, with either of the combine2 patches. And
all five are actually different (different symptoms,
On Sat, Nov 23, 2019 at 06:01:28PM -0500, Nicholas Krause wrote:
> Please just CC to this conversation as I keep getting removed.
Everyone who was on Cc: for this thread still is. This is how email
works. If you want to see everything on the list, subscribe to the
mailing list?
Segher
JUMP_P (insn))
> - continue;
Huh, I wonder where that came from. More archaelogy :-)
(This patch looks fine to me, fwiw).
Segher
On Sun, Nov 24, 2019 at 11:39:05AM -0600, Segher Boessenkool wrote:
> On Sun, Nov 24, 2019 at 03:19:49PM +0100, Bernd Schmidt wrote:
> > - /* This continue is deliberate. We do not want the uses of the
> > -jump put into reg_next_use because it is not considered safe to
&
On Sun, Nov 24, 2019 at 08:55:37PM +0100, Bernd Schmidt wrote:
> On 11/24/19 8:43 PM, Segher Boessenkool wrote:
> > But. Allowing autoinc into jump insns means those jump insns may then
> > eventually need an output reload; it may just have been because of that?
>
> That&#
y particular suggestions?
Segher
Hi!
On Mon, Nov 25, 2019 at 09:16:52PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > I am wondering the other way around :-) Is what you do for combine2
> > something that would be more generally applicable/useful? That's what
> > I'm tryi
On Mon, Nov 25, 2019 at 09:40:36PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > - i386 goes into an infinite loop compiling, or at least an hour or so...
> > Erm I forgot too record what it was compiling. I did attach a GDB... It
> > is something from l
Hi Mike,
On Mon, Nov 25, 2019 at 05:09:10PM -0500, Michael Meissner wrote:
> On Fri, Nov 22, 2019 at 06:06:19PM -0600, Segher Boessenkool wrote:
> > > --- gcc/config/rs6000/rs6000.c(revision 278173)
> > > +++ gcc/config/rs6000/rs6000.c(working copy)
> > > @@
On Mon, Nov 25, 2019 at 05:17:08PM -0500, Michael Meissner wrote:
> On Fri, Nov 22, 2019 at 06:20:52PM -0600, Segher Boessenkool wrote:
> > > (define_split
> > >[(set (match_operand:SI 0 "gpc_reg_operand")
> > > (match_operand:SI 1 "const_int_
On Mon, Nov 25, 2019 at 05:40:02PM -0500, Michael Meissner wrote:
> On Fri, Nov 22, 2019 at 06:32:08PM -0600, Segher Boessenkool wrote:
> > On Thu, Nov 14, 2019 at 05:44:42PM -0500, Michael Meissner wrote:
> > > This patch generates PADDI to add 34-bit immediate constants on
On Mon, Nov 25, 2019 at 05:52:29PM -0500, Michael Meissner wrote:
> On Fri, Nov 22, 2019 at 06:52:42PM -0600, Segher Boessenkool wrote:
> > On Thu, Nov 14, 2019 at 05:51:14PM -0500, Michael Meissner wrote:
> > > In some of my previous work, I had make a mistake forgetting tha
On Mon, Nov 25, 2019 at 11:08:47PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Mon, Nov 25, 2019 at 09:16:52PM +, Richard Sandiford wrote:
> >> Segher Boessenkool writes:
> >> > I am wondering the other way around :-) Is what you do for
when we get unwanted input. Such a
comment belongs where we prevent such code from being formed in the
first place (or nowhere, if it is obvious).
Segher
|| TARGET_PCREL_DEFAULT))
> + rs6000_isa_flags |= OPTION_MASK_PREFIXED_ADDR;
> +
> + if (!explicit_pcrel && TARGET_PCREL_DEFAULT
> + && TARGET_CMODEL == CMODEL_MEDIUM)
> + rs6000_isa_flags |= OPTION_MASK_PCREL;
> + }
> +}
... and I don't understand this code. If you use -mpcrel but you do not
have the medium model, you _do_ get prefixed but you do _not_ get pcrel?
And this all quietly?
Segher
; (ne:V8QI (reg:CC flags) (const_int 0))
> looks completely broken to me.
The original RTL is invalid already.
The patch should be harmless, but your bug is elsewhere?
Segher
*, *, *, *,
> + *, *, 2,
> + *, *,
> + *, *, *")
Different indent on the columns here (that is true elsewhere, too).
It would help a lot if you kept all columns the same width, too.
Okay for trunk with the changelog and the layout fixed. Thanks!
Segher
nd line should have one column more -- or
probably the first should have one less. Hard to tell, since it doesn't
use tabs to indent (as it should)).
Okay for trunk with the changelg and layout fixed. Thanks!
Segher
On Wed, Nov 27, 2019 at 02:01:05PM +0800, Kewen.Lin wrote:
> As Segher pointed out in PR92566, we shouldn't offer some vector modes which
> aren't supported under current setting. This patch is to make it check by
> VECTOR_UNIT_NONE_P which is initialized as current
her changelog entries
for how that is done. For this, you would say "Partial backport" or
something similar, since it is not a plain backport.
Okay for GCC 9. Thanks!
Segher
hould be clearer that something that produces
> a scalar can't have vector mode.
It's still not clear to me that
(ne:V1DI (reg:CC flags) (const_int 0))
produces a scalar: it explicitly produces a vector, instead! But it's
not clear what the semantics are, sure. Pity that it isn't documented.
Segher
On Wed, Nov 27, 2019 at 09:29:27AM +0100, Richard Biener wrote:
> On Tue, Nov 26, 2019 at 2:42 AM Segher Boessenkool
> wrote:
> > combine actually *calculates* DU chains almost completely, it just throws
> > away most of that information (it wants to have LOG_LINKS, as it did a
135 machine
> (powerpc64le-unknown-linux-gnu). OK?
Thanks :-)
Could you open a PR for the LRA problem please?
Segher
ed
> out), tree-core.h, tree.c, tree.h. Hopefully that will solve the
> offloading problem.
So your patch caused at least three problems, none of them completely
worked out yet, none of them trivial.
Maybe this isn't such a good idea during stage 3.
Segher
ent at all: the byte reverse instructions only exist in the
indexed form, so they will not match anymore.
This patch changes the patterns for the byte reverse instructions to
allow plain memory_operand, letting reload fix this up.
Tested on powerpc64-linux {-m32,-m64}, committing to trunk.
Segher
This implements the improvements I asked for. Committing.
Segher
2019-11-28 Segher Boessenkool
* config/rs6000/rs6000.md (*movsi_internal1): Fix formatting. Improve
formatting.
(*movdi_internal64): Ditto.
---
gcc/config/rs6000/rs6000.md | 192
* { dg-final { scan-assembler-times {\mnot\M} 2 { xfail be } } } */
> +/* { dg-final { scan-assembler-times {\mstd\M} 2 { xfail { {p8} && {be} } }
> } } */
I think you can write that as just
/* { dg-final { scan-assembler-times {\mstd\M} 2 { xfail { p8 && be } } } } */
Okay for trunk with or without such tweaks. Thanks, and sorry the review
took a while!
Segher
All of i386, m68k, s390, and tilegx are supported in QEMU (see
https://wiki.qemu.org/Documentation/Platforms for example), so they
should not have "S" (or "?" in that column).
---
htdocs/backends.html | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/htdocs/backends.html
On Mon, Nov 25, 2019 at 03:44:44PM +0100, John Paul Adrian Glaubitz wrote:
> On 11/25/19 3:40 PM, Segher Boessenkool wrote:
> > On Mon, Nov 25, 2019 at 01:38:53PM +0100, Tobias Burnus wrote:
> >> Thanks for the m68k work! Can you also update
> >> https://gcc.gnu.org/b
t; +/* { dg-options "-O2 -mdejagnu-cpu=future" } */
> +
> +/* Test that PADDI is generated to add a large constant. */
> +unsigned long
> +add (unsigned long a)
> +{
> + return a + 0x12345678UL;
> +}
> +
> +/* { dg-final { scan-assembler {\mpaddi\M} } } */
This will always succeed (it matches the ".file" line).
Segher
/* should generate STF. */
stfs.
> + *(double *)(p + 1) = d; /* should generate STD. */
stfd, instead.
Segher
twzu\M} } } */
That instruction does not exist anyway (it's stwu).
> +/* { dg-final { scan-assembler-not {\maddis\M} } } */
> +/* { dg-final { scan-assembler-not {\maddi\M}} } */
See above.
Segher
ong double ldouble;
"long double" isn't a specific type, not without other setup, but you
never use this one anyway. Well, none of these typedefs at all? So just
remove it all please.
> +typedef vector doublev2df;
> +typedef vector long v2di;
> +typedef vector float v4sf;
> +typedef vector int v4si;
> +#ifndef TYPE
> +#define TYPE ulong
> +#endif
(So adjust this one then).
Segher
ng v2di;
> +typedef vector float v4sf;
> +typedef vector int v4si;
> +
> +#ifndef TYPE
> +#define TYPE ulong
> +#endif
Same comment as before.
> +#if DO_VALUE
> +OTYPE
> +value (void)
> +{
> + return (OTYPE)a;
> +}
> +#endif
> +
> +#if DO_SET
> +void
> +set (ITYPE b)
> +{
> + a = (TYPE)b;
> +}
> +#endif
The casts here are not needed, and will only make problems harder to find?
Segher
*/
> +/* { dg-final { scan-assembler {\mpstd\M} } } */
So what it actually tests is if we use prefixed loads and stores for
the stack protector generated code?
Segher
REL_OPT,.-(.Lpcrel1-8)
b 2f
here: # some code that does not explicitly reference r10 here,
# but r10 is live here nevertheless, and is used later
b somewhere_else
2: lwz 10,0(9)
complicates your analysis, too. So something DF is needed here, or
there are lots and lots and lots of cases to look out for.
Segher
better match to what we want there.
> 2019-12-03 Kewen Lin
>
> PR target/92760
> * gcc/config/rs6000/rs6000.c (rs6000_preferred_simd_mode): Update
> VECTOR_UNIT_NONE_P by VECTOR_MEM_NONE_P.
(Maybe better is "Use VECTOR_MEM_NONE_P instead of VECTOR_UNIT_NONE_P."?)
Okay for trunk. Thanks!
Segher
On Tue, Dec 03, 2019 at 10:33:48PM +0900, Oleg Endo wrote:
> On Mon, 2019-11-25 at 16:47 -0600, Segher Boessenkool wrote:
> >
> > > > - sh (that's sh4-linux):
> > > >
> > > > /home/segher/src/kernel/net/ipv4/af_inet.c: In function
> > &
ches once again after the reformating.
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01605.html
This is six weeks ago. And I do not know if what you call "v6" is this.
Segher
On Tue, Dec 03, 2019 at 01:11:55PM -0500, Michael Meissner wrote:
> On Fri, Nov 22, 2019 at 08:11:16PM -0600, Segher Boessenkool wrote:
> > On Thu, Nov 14, 2019 at 05:56:50PM -0500, Michael Meissner wrote:
> > > * lib/target-supports.exp
> > > (check_effective_target
On Tue, Dec 03, 2019 at 01:20:04PM -0500, Michael Meissner wrote:
> On Tue, Nov 26, 2019 at 01:20:20PM -0600, Segher Boessenkool wrote:
> > > I needed to add a new constraint (em) in addition to new predicate
> > > functions.
> > > I discovered that with the predicat
tes as such insns exist. And leave it to
> emit_conditional_move which decides whether it can be optimized or not.
I don't think we should pretend we have any conditional jumps the
machine does not actually have, in cbranchcc4. When would this ever be
useful? cror;beq can be quite expensive, compared to the code it would
replace anyway.
If something generates those here (which then ICEs later), that is
wrong, fix *that*? Is it ifcvt doing it?
Segher
ch config/rs6000/ at all.
Segher
Hi!
On Thu, Nov 17, 2022 at 02:59:00PM +0800, Kewen.Lin wrote:
> on 2022/11/17 02:44, Segher Boessenkool wrote:
> > On Wed, Nov 16, 2022 at 02:48:25PM +0800, Kewen.Lin wrote:
> >>* config/rs6000/rs6000.cc (rs6000_emit_vector_compare_inner): Remove
> >>floa
Hi!
On Thu, Nov 17, 2022 at 03:52:26PM +0800, Kewen.Lin wrote:
> on 2022/11/17 02:58, Segher Boessenkool wrote:
> > On Wed, Nov 16, 2022 at 02:51:04PM +0800, Kewen.Lin wrote:
> >>/* In vector.md, we support all kinds of vector float point
> >> comparison op
Hi!
On Mon, Nov 21, 2022 at 02:18:39PM +0800, HAO CHEN GUI wrote:
> 在 2022/11/18 20:18, Segher Boessenkool 写道:
> > I don't think we should pretend we have any conditional jumps the
> > machine does not actually have, in cbranchcc4. When would this ever be
> > usef
)
> > +{
> > + *arg++ = 0x98765432ULL;
> > + *arg++ = 0x7cdeab55ULL;
> > + *arg++ = 0x6543ULL;
> > +}
Use noipa please (it is shorter, simpler, and covers more :-) )
Could you comment what exact instructions are expected?
li;xoris and li;xoris and lis;xoris I guess? It helps if you just tell
the reader here.
The li;oris and li;xoris parts look good.
Segher
Hi!
On Fri, Nov 25, 2022 at 09:21:21PM +0800, Jiufu Guo wrote:
> "Kewen.Lin" writes:
> > on 2022/9/15 16:30, Jiufu Guo wrote:
> >> For a complicate 64bit constant, blow is one instruction-sequence to
> >> build:
> >>lis 9,0x800a
> >>ori 9,9,0xabcd
> >>sldi 9,9,32
> >>oris 9,9,0xc1
Hi!
Whoops I missed following up to this.
On Mon, Nov 21, 2022 at 10:01:14AM +0800, Kewen.Lin wrote:
> on 2022/11/18 23:10, Segher Boessenkool wrote:
> > ge is nasty for float, it means something different with and without
> > -ffast-math (with fast-math ge means not lt, le mea
On Mon, Nov 28, 2022 at 11:37:34AM +0800, Jiufu Guo wrote:
> Segher Boessenkool writes:
> > On Fri, Nov 25, 2022 at 04:11:49PM +0800, Kewen.Lin wrote:
> >> on 2022/10/26 19:40, Jiufu Guo wrote:
> >> for "li/lis + oris/xoris", I interpreted it into four combi
On Mon, Nov 28, 2022 at 03:51:59PM +0800, Jiufu Guo wrote:
> Jiufu Guo via Gcc-patches writes:
> > Segher Boessenkool writes:
> >>> > + else
> >>> > + {
> >>> > + emit_move_insn (temp,
> >>> > +
are f0 <=> f1 to cr0 (exactly one of
# cr0.lt, cr0.gt, cr0.eq, cr0.un will be set)
cror 2,0,1# cr0.eq = cr0.lt | cr0.gt
beq 0 # branch if cr0.eq is set
So, we want the cbranchcc4 here to just do that last insn, not the last
two insns (or all three as any other cbranch4 is!)
Segher
nsn
> must not fail?
This will work the same as with any other define_expand? If the caller
of gen_blablabla does not check for failure, you end up with a NULL_RTX
in the instruction stream, which will ICE sooner or later. Not pretty,
sure, but at least it is a reliable ICE :-)
Segher
nsn *seq = combine_split_insns (gen_rtx_SET (reg, XEXP (x, 0)),
> -subst_insn);
> + rtx_insn *seq
> + = combine_split_insns (gen_rtx_SET (reg, XEXP (x, 0)), subst_insn);
The original was better.
For big mechanical patches, please do only *one* thing per patch, so all
the patches in the series will be totally boring and much MUCH easier to
review. But again, I think it is a mistake to make predicates for PLUS
and MINUS and such. Sorry. PLUS is frequent in this patch, but MINUS
and MULT are not at all, and even PLUS is not common in our code. A few
characters shorter is nice for *very* common things, but extra
expressiveness through verbosity is worth more here, imo.
Segher
ch we sometimes need to look
> back on, and RTL is some of the oldest code in the compiler, so we want
> to minimize "churn" to keep tools like "git blame" useful.
Not to mention that many of those changes violated our coding style, or
even look like an automated formatter going haywire. And, of course,
such changes should be separate patches, if done at all!
Segher
2701 - 2800 of 6092 matches
Mail list logo
