that, heh.
But it's fine, the insn patterns it uses use the same conditions
already.
Segher
rget-supports.exp change plus
> there is no mention of why it's needed in the git log entry.
In the commit message you mean? Yeah. This info belongs in the commit
message.
Is the target-supports thing that Cell thing? That does not belong here
at all. If it wasn't simply a mistake, it should be a separate commit,
with a lot of explanation.
Segher
On Sat, May 25, 2024 at 09:12:05AM -0300, Alexandre Oliva wrote:
You sent multiple patch series in one thread, and multiple versions of
the same series even.
This is very hard to even *read*, let alone work with. Please don't.
Segher
maybe, but don't try to "optimise" that expression, let the compiler
do that, it is much better at it anyway :-) )
> +}
Is that correct for all ABIs we support? Even if so, it needs a lot
more documentation than this.
Segher
s what it defines;
> > 3) optab defined, FAIL, generate a library call;
> >
> > From above, I had the concern that ports may assume FAILing can
> > fall back with the generic folding, but it's not actually.
>
> Hmm, but it should. Can you make that work?
That certainly would be the least surprising!
Segher
he builtin, right? So write that instead?
"Return 1 if the operand (a scalar floating poiint number) is finite",
or such?
Segher
nu. Are these the sort of test case you're interested
> in, or are you looking for something that tests the offsets in debug
> info, rather than the end-to-end debugging feature?
A testcase specifically for this would be good, yes. Where you can say
at the top of the file "This tests that ... [X and Y]" :-)
Segher
Hi Alex,
On Thu, May 30, 2024 at 01:40:27PM -0300, Alexandre Oliva wrote:
> Sorry, I misnumbered this patch as #1/2 when first posting v3.
I see at least five completely different patches in this email thread,
with different subjects and all.
> On May 28, 2024, Segher Boessenkool
s would be WAY easier to review (read: AT ALL POSSIBLE) if you
included some detailed rationale and design document.
Segher
On Fri, May 31, 2024 at 09:14:21AM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > Hi!
> >
> > On Fri, May 31, 2024 at 01:21:44AM +0530, Ajit Agarwal wrote:
> >> Code is implemented with pure virtual functions to interface with target
> >>
ose to actually
include this patch :-)
> Bootstrapped/regtested on powerpc64le-linux and powerpc64-linux (-m32/-m64
> testing there), ok for trunk and after a while for release branches?
Yes please. What nastiness. Thanks for dealing with it!
Segher
> 2024-06-03 Jakub Jelinek
ot a VSX insn (for which MSR[VSX]=1 is needed).
We test TARGET_ALTIVEC for that, not TARGET_VSX.
In general, we want to get rid of TARGET_Pxxx_VECTOR, not introduce new
stuff like it!
Segher
On Fri, Aug 09, 2024 at 03:50:50PM -0500, Peter Bergner wrote:
> On 8/9/24 12:54 PM, Segher Boessenkool wrote:
> >> --- a/gcc/config/rs6000/altivec.md
> >> +++ b/gcc/config/rs6000/altivec.md
> >> @@ -623,7 +623,7 @@ (define_insn "altivec_eqv1ti&q
well-formed, but it doesn't make sense, indeed :-) Named patterns
have requirements on their arguments, but everything else is whatever
the target wants :-)
Hopefully *no* passes will consider this a pure input, we have that "+"
after all! It would be better if it wasn't there, sure.
Segher
Hi!
On Mon, Aug 12, 2024 at 10:42:48AM +0800, Kewen.Lin wrote:
> on 2024/8/10 05:43, Segher Boessenkool wrote:
> IIUC, we want to split TARGET_P[89]_VECTOR into TARGET_P[89]_ALTIVEC and
> TARGET_P[89]_VSX (or just TARGET_POWER[89] && TARGET_VSX or TARGET_ALTIVEC)
> according
bit
even.
This is handy for people reading the ISA, like most of us: the
instruction descriptions talk about MSR[VEC] and MSR[VSX] all over the
place. And people will less easily understand this as being about just
the old insns!
Segher
On Mon, Aug 12, 2024 at 10:59:01AM -0500, Peter Bergner wrote:
> Ping * 3. [Message-ID: <1e003d78-3b2e-4263-830a-7c00a3e9d...@linux.ibm.com>]
>
> Segher, this resolves the issues you mentioned in your review.
> This was on the top of your patch review queue before, so may
Also
okay with just the MODE_UNIT_SIZE (mode) == 16 thing, after you tested
that of course :-)
Thanks!
Segher
or you don't care about that target, or just
cargo-cult, is wrong, and encourages more wrongness.
Segher
he constant into a register", yes.
> --- a/gcc/testsuite/gcc.target/powerpc/pr106550_1.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr106550_1.c
> @@ -4,17 +4,19 @@
> /* { dg-options "-O2 -mdejagnu-cpu=power10 -fdisable-rtl-split1" } */
> /* force the constant splitter run after RA: -fdisable-rtl-split1. */
>
> +/* The below marco helps to avoid using paddi and avoid loading from memory.
> */
(macro)
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr63281.c
> @@ -0,0 +1,11 @@
> +/* Check loading constant from memory pool. */
> +/* { dg-options "-O2 -mpowerpc64" } */
> +
> +void
> +foo (unsigned long long *a)
> +{
> + *a++ = 0x2351847027482577ULL;
> +}
> +
> +/* { dg-final { scan-assembler-times {\mp?ld\M} 1 { target { lp64 } } } } */
Why target lp64 only? You have -mpowerpc64 already, does that not make
us use ld here always?
Segher
0;
> +}
> +
> +/* { dg-final { scan-assembler "power4" } } */
Please explain (in the testcase, not here!) what this is meant to test!
You probably want to say {\mpower4\M} instead, btw. Unless you want to
match ".machine spower436" as well?
Segher
} 1 } } */
> +/* { dg-final { scan-assembler-times {\m(?:xxsel|xxlor|vor)\M} 1 } } */
> /* { dg-final { scan-assembler-not {\mvspltisw\M} } } */
> /* { dg-final { scan-assembler-not {\mxxlorc\M} } } */
Okido, thanks! The three trivial tweaks I suggest here are okay as
well if you want, after testing of course ;-)
Segher
On Wed, Jun 12, 2024 at 07:02:31PM -0500, Peter Bergner wrote:
> On 6/12/24 3:00 PM, Segher Boessenkool wrote:
> >> /* { dg-do compile { target { powerpc64*-*-* } } } */
> >
> > Probably should be an "lp64" instead?
>
> Actually, there is nothing in
! has_arch_pwr8
> } } } */
> /* { dg-require-effective-target powerpc_vsx } */
Everything in gcc.target/powerpc/ is tested for "target powerpc*-*-*"
already, so you could remove that target clause even (after testing of
course :-) )
Okay for trunk with or without that extra tweak. Thank you!
Segher
/
> +/* { dg-options "-O2 -mdejagnu-cpu=power8" } */
> +/* { dg-require-effective-target p8vector_hw } */
I have no idea why the original didn't do -O2 already, heh. So this is
only an improvement, right! I won't complain at all unless it fails :-)
Segher
p the size of the
> rs6000_init_generated_builtins function quite a lot.
> The above patch decreases it back, to even less than the size of
> the function before my fix.
A patch in the middle of a thread. I missed it, sorry. Please send
patches as separate threads?
Segher
e compiler with LTO to undo that optimization. */
Some of these array names no longer have the rs6000_ prefix now. Oh
wait, you already took that into account? I'm not saying anything :-)
The patch is fine for trunk, thank you! If you want backports those
are okay, too (but I don't think you want any? Or does this work
withput the previous patches as well?)
Segher
p. */
> - if (rs6000_rop_protect)
> -flag_shrink_wrap = 0;
> }
(Yes, I know the original code didn't say either, but let's try to make
things better :-) )
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr114759-1.c
> @@ -0,0 +1,16 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -mdejagnu-cpu=power10 -mrop-protect
> -fdump-rtl-pro_and_epilogue" } */
> +/* { dg-require-effective-target rop_ok } */
Do you want rop_ok while you are *forcing* it to be okay anyway? Why?
Segher
Hi!
On Mon, Jun 17, 2024 at 06:49:18PM -0500, Peter Bergner wrote:
> On 6/17/24 6:11 PM, Segher Boessenkool wrote:
> >> - /* If we are inserting ROP-protect instructions, disable shrink wrap.
> >> */
> >> - if (rs6000_rop_protect)
> >> -flag_shrink_
On Mon, Jun 17, 2024 at 08:54:46PM -0500, Peter Bergner wrote:
> On 6/17/24 7:57 PM, Segher Boessenkool wrote:
> > On Mon, Jun 17, 2024 at 06:49:18PM -0500, Peter Bergner wrote:
> >> On 6/17/24 6:11 PM, Segher Boessenkool wrote:
> >> Yeah, I didn't write that, I
the widen
things, don't try to do the compilers job of specialising stuff, it
only makes things much less readable, and causes more mistakes. Just do
like what was there before, essentially.
Segher
On Tue, Jun 18, 2024 at 12:53:09PM -0500, Peter Bergner wrote:
> On 6/18/24 8:20 AM, Segher Boessenkool wrote:
> > On Mon, Jun 17, 2024 at 08:54:46PM -0500, Peter Bergner wrote:
> >> So we should be able to shrink-wrap in the presence of the ROP protection.
> [snip]
> &
works
best for you :-)
> Bootstrapped and regtested on powerpc64-linux-gnu P8/P9
> and powerpc64le-linux-gnu P9 and P10.
That also tested -m32 (on BE at least), right?
Okay for trunk, thanks for dealing with this!
Segher
I didn't see this before. Sigh.
On Tue, Jan 02, 2024 at 09:47:11AM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Tue, Oct 24, 2023 at 07:49:10PM +0100, Richard Sandiford wrote:
> >> This patch adds a combine pass that runs late in the pipeline.
>
run, one for compiling only. It's
a bit simpler and cleaner.
> +/* { dg-options "-mdejagnu-cpu=power10 -save-temps" } */
Why the -save-temps? Always document it if you want that for something,
but never put it in the testcase if not. A leftover from development?
Okay for trunk, thank you! Well Peter had some comments too, modulo
those I guess, I'll read them now ;-)
Segher
R))]
> >"TARGET_POWER10"
>
> I know the old code used the register_operand predicate for the vector
> operands, but those really should be changed to altivec_register_operand.
register_operand is just fine usually. The "v" constraint already makes
sure things end up in a VMX (a lower VSX) register, the predicate
doesn't help here. register_operand is shorter (and thus, preferred),
and also more likely correct if the code changes later :-)
Segher
On Wed, Jul 24, 2024 at 12:12:05PM -0500, Peter Bergner wrote:
> On 7/24/24 12:06 PM, Segher Boessenkool wrote:
> I thought we always wanted the predicate to match the constraint being used?
Predicates and constraints have different purposes, and are used at
different times (typ
On Wed, Jul 24, 2024 at 12:16:33PM -0500, Peter Bergner wrote:
>
> On 7/24/24 12:03 PM, Segher Boessenkool wrote:
> >> +/* { dg-options "-mdejagnu-cpu=power10 -save-temps" } */
> >
> > Why the -save-temps? Always document it if you want that for something,
Hi!
On Wed, Jul 24, 2024 at 11:38:11AM -0700, Carl Love wrote:
> On 7/24/24 10:03 AM, Segher Boessenkool wrote:
> >So much manual stuff needed, sigh.
> >
> >On Fri, Jul 19, 2024 at 01:04:12PM -0700, Carl Love wrote:
> >>gcc/ChangeLog:
> >> * c
> to be used but
> > it's a bit more meaningful (especially we already have mpower10),
> > theoretically speaking
> > it's undocumented users shouldn't use it at all.
>
> Sorry, I should have mentioned this, but I originally had it -mpower8, but
> given
> it wa
erence at all anyway,
it always has set the invalid flag after all.
Thanks!
Segher
It does not
make any sense.
Is there any place where newpat is used uninitialised?
Segher
same true for many other objects that are initialized
> lazily?
For all, even.
Without this change the compiler can (in theory, anyway) diagnose the
uninitialised use. After, there *is* no uninitialised use anymore.
Please don't do this. It is not an improvement, it is several steps
back, to satisfy a misguides sense of "security".
Segher
st return zero (unknown), so the
> comment holds to pattern_cost the same (it returns an 'int' so the better
> exceptional value would have been -1, avoiding the compare).
Cost 0 for unkown is used in (almost) *all* cost things in RTL. Pretty
much everything can deal with it just fine. What is different here?
The abstraction "pattern_cost" is a lousy abstraction of course, but
where is this used? Cost "unknown" can be passed through everywhere,
in principle.
Segher
eptional value would have been -1, avoiding the compare).
> But sometime it adds an insn cost. If the unknown cost is -1, the total cost
> might be distorted.
*All* code using a cost will have to be inspected and possibly adjusted
if you decide to use a different value for "unknown" than what we have
had for ages. All other cost functions interacting with this one, too.
Segher
On Fri, May 10, 2024 at 12:19:35PM +0200, Richard Biener wrote:
> On Fri, May 10, 2024 at 11:06 AM Segher Boessenkool
> wrote:
> > *All* code using a cost will have to be inspected and possibly adjusted
> > if you decide to use a different value for "unknown" than w
.
Most things already use only insn_cost, if you have the appropriate
hooks implemented in your backend (all one of them even). This is so
much easier to use (you only need to recognise some big categories of
instructions, for a typical target core, instead of eighty different
RTX codes, and the combination of them), and gives way better results.
Segher
u
*have to* have mem here?
The code you add that tests for address_operand looks wrong. I would
expect it to test the operand is memory, instead :-)
Segher
> +++ b/gcc/testsuite/gcc.target/powerpc/pr89213.c
> @@ -0,0 +1,106 @@
> +/* { dg-do compile { target { lp64 } } } */
Why only on 64-bit systems? Does it fail with -m32? Why / how?
With that, okay for trunk. Thanks!
Segher
to me it
should be if (TARGET_ALTIVEC_ABI && TARGET_ALTIVEC_VRSAVE) in
the first place, and then you don't need the change when changing
the default for -mvrsave like this patch does?
Segher
It was used for old POWER only, which has been removed.
Tested etc.; okay to apply?
Segher
2012-10-04 Segher Boessenkool
gcc/
* config/rs6000/rs6000.c (print_operand) ['A']: Delete.
---
gcc/config/rs6000/rs6000.c | 11 ---
1 files changed, 0 insertions(+), 11
As David noticed, I forgot PRINT_OPERAND_PUNCT_VALID_P in the patch
that removed %. This fixes it.
Bootstrapped and regression tested on powerpc64-linux. Okay to
apply?
Segher
2012-10-09 Segher Boessenkool
gcc/
* config/rs6000/rs6000.h (PRINT_OPERAND_PUNCT_VALID_P
This fixes all warnings from the machine description (mostly these
were missing modes).
Bootstrapped and tested on powerpc64-linux; no regressions. The
testsuite covers all changed patterns.
Okay for mainline?
Segher
2012-10-18 Segher Boessenkool
* gcc/config/rs6000/altivec.md
using helper functions for
the regular groups. It's easy to make a more efficient data structure
as well then.
Segher
unexpected failures 126
-# of unresolved testcases 63
+# of expected passes 8790
Not bad for a one-liner :-)
Bootstrapped and tested on powerpc64-linux, -m64,-m32,-m32/-mpowerpc64;
no new failures, and the above improvements.
Okay to apply?
Segher
2012-10-25 Segher
powerpc64-linux -m64,-m32,-m32/-mpowerpc64.
Okay to apply?
Segher
2012-10-25 Segher Boessenkool
gcc/
* config/rs6000/rs6000.md (sign_extend:SI patterns): Split
the memory case off. Merge the two register cases. Change
the condition for the memory case to require 64
hat passed without either patch, but
failing is correct -- wrong code sometimes runs fine :-)
So I'm not applying this patch. I don't think we need a configure
check: we have had many releases with these bugs already, one more
won't hurt. People generally use a recent version of binutils as well.
Segher
targets with ASSEMBLER_DIALECT;
- ia64 (for stop bits);
- mep, and this one is easily fixed.
- basic asms do not get TARGET_MD_ASM_ADJUST.
Segher
c; is this okay for mainline?
Segher
2016-01-26 Segher Boessenkool
* config/rs6000/rs6000.c (print_operand): Rollback 's' removal.
---
gcc/config/rs6000/rs6000.c | 8
1 file changed, 8 insertions(+)
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000
On Tue, Jan 26, 2016 at 01:11:36PM +0100, Bernd Schmidt wrote:
> On 01/26/2016 01:29 AM, Segher Boessenkool wrote:
>
> >In my opinion we should not warn for any asm that means the same both
> >as basic and as extended asm. The problem then becomes, what *is* the
> >mean
powerpc64-linux. OK for stage1?
>
> Note that this bug was found when investigating why gcc-6 does not
> suffer from pr69548, ie. this bug was masking a powerpc backend bug.
It sounds like you have a testcase, can we see it please?
And, just a missed optimisation, not a bug, ri
As it happens the patch I did over a year ago for PR64682 isn't quite
correct. This is PR69567. This fixes it.
Tested on the separate testcases; also did bootstrap + testsuite on
powerpc64-linux and x86_64-linux. I'll commit this tomorrow or so if
no one sees something wrong with it
This testcase fails on 32-bit powerpc-linux with
Excess errors:
/home/segher/src/gcc/gcc/testsuite/c-c++-common/vector-compare-4.c:31:1:
warning: GCC vector returned by reference: non-standard ABI extension with no
compatibility guarantee
Fix this as in vector-compare-2.c .
Tested on
On Tue, Feb 02, 2016 at 11:32:08AM +, Segher Boessenkool wrote:
> As it happens the patch I did over a year ago for PR64682 isn't quite
> correct. This is PR69567. This fixes it.
>
> Tested on the separate testcases; also did bootstrap + testsuite on
> powerpc64-li
On Sat, Feb 06, 2016 at 09:54:25AM -0800, H.J. Lu wrote:
> On Thu, Feb 4, 2016 at 3:28 PM, Segher Boessenkool
> wrote:
> > On Tue, Feb 02, 2016 at 11:32:08AM +, Segher Boessenkool wrote:
> >> As it happens the patch I did over a year ago for PR64682 isn't quite
>
powerpc64-linux. OK for stage1?
It looks good, but please post it again then.
Segher
could you test it on your setup before I apply it there though?
Segher
2016-02-11 Segher Boessenkool
PR rtl-optimization/64682
PR rtl-optimization/69567
PR rtl-optimization/69737
* combine.c (distribute_notes) : If the register is set
in I2 as well,
}
> +SUBST (SET_DEST (i2mod_new_rhs), new_dest);
> + }
Let's not SUBST outside of try_combine please. It probably works, but
there is enough action-at-a-distance as it is.
Segher
On Thu, Feb 18, 2016 at 09:41:49AM +1030, Alan Modra wrote:
> On Wed, Feb 17, 2016 at 06:31:45AM -0600, Segher Boessenkool wrote:
> > > Corresponding content of "op" which causes the ICE:
> > > gdb) p debug_rtx (op)
> > > (gtu:SI (reg:CC 166) -
anges any
REG_EQUAL and REG_EQUIV notes referring to the pseudo as well, which
makes them invalid. This patch finds such notes and deletes them in
these cases.
Testing on powerpc64-linux; will also test on x86_64-linux before
committing.
Segher
2016-02-19 Segher Boessenkool
PR
On Fri, Feb 19, 2016 at 11:27:48AM +0100, Eric Botcazou wrote:
> > 2016-02-19 Segher Boessenkool
> >
> > PR 60818/rtl-optimization
> > * combine.c (combine_remove_reg_equal_equiv_notes_for_regno):
> > New function.
> > (try_combine): Call it
es can contain an arbitrary expression in general.
Not for stage 4 certainly.
> > But it never adds or moves these notes. It even says so :-)
>
> Right, but try_combine can do it, see line 4294 and below.
That moves those notes to i2notes, and then distribute_notes drops them?
Segher
we
do have a problem if i2 is a parallel with only one SET; but we already
had a problem anyway? The REG_EQ* is put on the wrong insn?
Segher
> to touch unless you really need to.
Oh I agree, which is why I throw all patches through testing on a zillion
different archs, and bootstraps on a few.
I'll postpone this patch to GCC 7, stage 4 is too late for it.
Segher
ed on powerpc64-linux, -m32,-m64 and -mlra,-mno-lra. Also
tested the new test on powerpc64le-linux (where the test is skipped).
Is this okay for trunk?
Segher
2016-02-24 Segher Boessenkool
PR target/69946
* config/rs6000/rs6000.c (rs6000_insn_for_shift_mask): Print rlwinm
,%3,%4";
- return "rlw%I2nm %0,%1,%2,%3,%4";
+ return "rlw%I2nm. %0,%1,%h2,%3,%4";
+ return "rlw%I2nm %0,%1,%h2,%3,%4";
}
gcc_unreachable ();
Segher
nd.
Yes, curious. But when it was written it *did* match. Huh.
> Is there any particular reason that subf<>3_carry_in_m1 was written with
> minus rather than plus like all of the other patterns?
It's what RTL simplification comes up with, so it is the only thing
combine tries. The same reason why there are separate patterns for 0
and -1 at all.
Segher
t hadn't really mattered.
It failed more recently though, that's what r215429 is about. Oh, before
that it did test just the code, didn't use register_operand. *facepalm*
Segher
+ /* Perform rematerialization if only all operands are registers and
> + all operations are PLUS. */
> + for (i = 0; i < n_ops; i++)
> + if (ops[i].neg || !REG_P (ops[i].op))
> + return NULL_RTX;
> + goto gen_result;
> +}
If you check for fixed registers as well here, does that work for you?
Segher
On Fri, Feb 26, 2016 at 01:10:17PM -0800, Richard Henderson wrote:
> On 02/26/2016 01:01 PM, Segher Boessenkool wrote:
> >> How do you imagine the rs6000 change will regress codegen?
> >
> > Combine of sequences with double-length adds.
>
> What sort of test cas
On Fri, Feb 26, 2016 at 01:35:10PM -0800, Richard Henderson wrote:
> On 02/26/2016 01:03 PM, Segher Boessenkool wrote:
> > On Thu, Feb 25, 2016 at 09:08:32PM -0800, Richard Henderson wrote:
> >> + /* Perform rematerialization if only all operands are registers and
patterns. There can and will be side
effects. You're replacing a lot of RTL generation by open-coded stuff,
that's the wrong direction.
You're putting all the risk on a different backend for fixing a minor
regression in x86.
Segher
x27;m vaguely aware there have been changes to extzv etc. so there now are
extzv; I'll investigate if that means anything for insv as well.
It's also a new #ifdef HAVE_xxx. But we're not clean there yet so I hope
to get away with that ;-)
Comments? Complaints?
Segher
---
gcc/comb
mless stuff, but the rtx_costs one
at least probably wants fixing soonish.
Oh, and this patch should be applied after the HAVE_insv patch I posted
earlier today, for good results.
Is this okay for trunk?
2015-07-12 Segher Boessenkool
PR target/66217
* config/rs6000/constrai
ur approach looks fine to me -- assuming you want to have a
fake "abs" insn at all.
On to the patch...
> +;; Combine will try merging (c > 0 ? -x : x) into (-|x|). This isn't a good
"x > 0" here.
Segher
combined from three insns, while a define_insn handles it
being combined from two as well.
A define_split will be split during combine (and combine can then work
on its factors); a define_insn is only split _after_ combine.
Segher
ook like the if_then_else stuff in combine (and simplify-rtx)
could use some improvement, probably more than just fixing this one
case. Or look at the first huge case in combine_simplify_rtx, that
looks eerily similar.
Segher
On Mon, Jul 13, 2015 at 10:50:28PM -0600, Jeff Law wrote:
> On 07/12/2015 07:56 AM, Segher Boessenkool wrote:
> >Currently combine tries to make assignments to bitfields (of a register)
> >whenever it can. If the target has no insv pattern, the result will not
> >ever match
On Wed, Jul 15, 2015 at 12:10:51PM +0930, Alan Modra wrote:
> There are one or two regressions related to a TODO that Segher added.
> The following produces poorer code than mainline.
Yes, that's why it says TODO :-)
> Also, rs6000.md patterns uses SImode for the rotate/shift count
On Thu, Jul 16, 2015 at 04:25:14PM +0100, Kyrill Tkachov wrote:
> Hi all,
>
> This is an attempt to solve the problem in the thread starting at
> https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01010.html
> in a generic way after some pointers from Segher and Andrew.
>
> The p
that work?
Which brings the question why it wasn't there in the first place, hrm.
Segher
). The newly generated
pattern is simper alright, but the backend didn't recognise it. With a
simple patch, it does, and the generated code is nicely better than
before.
The hppa64 problem looks similar. Maybe other targets could use such
an improvement as well.
So yes, the patch is fine. Thank you for working on it Kyrill :-)
Segher
Hi all,
Two updates for the rotate revamp, and a third patch that won't apply
without it. I'll fold the first two together with the big patch, if
approved.
Everything bootstrapped and tested on powerpc64-linux, as usual; no
regressions.
Segher
Segher Boessenkool (3):
Doc fix
This removes the removed constraints from the documentation. It also
removes "q" (for MQ) which hasn't existed for a while.
2015-07-20 Segher Boessenkool
* config/rs6000/constraints.md: Update "available letters" comment.
* doc/md.texi (Machine Con
This changes the shift amount to always be SI (as it should be), not GPR.
It doesn't matter for constant shifts, but there are some variable shifts
as well, and consistency is good.
No changelog, I'll fold it into the previous big patch, if approved.
Segher
---
gcc/config/rs6000
-mask instruction.
Previously, combine usually came up with a more complex pattern (that
we do implement), hiding the issue.
This patch adds a define_insn for the pattern.
2015-07-20 Segher Boessenkool
* config/rs6000/rs6000.md (*lt0_disi): New.
---
gcc/config/rs6000/rs6000.md
e any others.
vmx.exp sets a bunch of options and the test overrides that now. Options
like -maltivec are pretty important for this test to work -- it #includes
altivec.h, which does #error unless -maltivec is set, and things go downhill
from that. unpack-be-order.c works, unpack.c blows up.
Does your compiler maybe default to -maltivec?
Segher
selection in general; it only does
instruction combination. It already handles most cases where shifts
and masks are combined; if you find one where it doesn't, please
report.
Segher
t doesn't afaik. But can't you define INITIAL_FRAME_ADDRESS_RTX?
Segher
,
-m64,-m64/-mlra}; no regressions. Code size on both 32-bit and 64-bit
improves.
Is this okay for trunk?
Segher
2015-07-23 Segher Boessenkool
PR target/66217
* config/rs6000/rs6000-protos.h (rs6000_emit_2insn_and): Change
prototype.
* config/rs6000/rs6000.c
1501 - 1600 of 6091 matches
Mail list logo
