Andrew Church */
> /* { dg-do run } */
> /* { dg-require-effective-target untyped_assembly } */
> +/* { dg-additional-options "-fno-rename-registers" { target { powerpc*-*-* }
> } } */
What is this for? What happens without it?
The rs6000/ parts are okay for trunk. Thanks!
Segher
;
>
> - emit_insn (gen_anddi3 (element, element, num_ele_m1));
> + /* Make sure the element number is in bounds. */
> gcc_assert (REG_P (tmp_gpr));
How does that make sure the number is in bounds?
In general, do asserts as early as practical?
Segher
, or should it be reg_mentioned_p?
This whole function is too complex (and it writes TARGET_POWERPC64 where
it needs TARGET_64BIT, for example).
The patch is okay for trunk (with the comment moved, and the rtx_equal_p
fixed). Thanks!
Segher
2DF extract
> +;; Variable V2DI/V2DF extract. Use 'Q' for the memory because we will
> +;; ultimately have to convert the address into base + index.
Maybe just don't write anything at all, since it is hard to explain in a
few words? It is clear that "Q" is not a usual constraint, anyway :-)
Okay for trunk like that. Thanks!
Segher
t;
Arm has
(define_memory_constraint "Q"
"@internal
An address that is a single base register."
(and (match_code "mem")
(match_test "REG_P (XEXP (op, 0))")))
which is more correct for us (the register cannot be r0!)
But it is not an address.
Maybe "A memory operand addressed by just a base register." ?
Okay for trunk like that. Thanks!
Segher
trunk. Thanks!
Segher
> 2019-12-23 Jiufu Guo
>
> * gcc/config/rs6000/rs6000.c
> (rs6000_option_override_internal): Enable -fweb and -frename-registers
> with -funroll-loops
loads are
> + allowed. */
> + else if (pcrel_local_address (new_addr, Pmode))
> +{
> + addr_mask_type addr_mask
> + = rs6000_reg_to_addr_mask (scalar_reg, scalar_mode);
> +
> + valid_addr_p = (addr_mask & RELOAD_REG_OFFSET) != 0;
> +}
That comment could be better, too? (And two letters "t" in offsettable).
Thanks,
Segher
for trunk. Thanks!
> 2020-01-02 Martin Liska
>
> PR tree-optimization/92860
> * params.opt: Mart param_max_combine_insns with Optimization
> keyword.
s/mart/mark/
(Btw, does this help -Og at all? If so, shouldn't it be -O1 as well?)
Segher
s. Use rs instead of doing
> > GEN_INT again.
> >
> > * gcc.target/powerpc/pr93122.c: New test.
> I think this is fine, but give the PPC maintainers a few days to chime
> in.
It's not okay, whether I'll need a few days or more to reply. But I will
reply soon :-)
Segher
g of
> loop properties.
Right, or at least store how much the current plan says to unroll each
loop, so that all passes can take that into account, or even adjust it
if that is a good idea.
Segher
atch
newlines. This is often what you want. This RE also makes sure that
"hashchk" is the full mnemonic (not the tail of one), and that it is on
the line after that "ld".
Similarly you would have
/* { dg-final { scan-assembler {(?p)\mmflr 0,.*\n.*\mhashst 0,} } } */
I hope I didn't typo those things, I didn't test them out :-)
Okay for trunk with similar robustification. Thanks!
Segher
_128 && !TARGET_IEEEQUAD)
> +{
> + icode = CODE_FOR_unpacktf;
> + fcode = RS6000_BIF_UNPACK_TF;
> + uns_fcode = (size_t)fcode;
> +}
(same issues)
> + switch (nargs)
> +{
> +default:
Just Say No. Don't write 0 == err and don't put default: first. It
does not improve your code. It makes it worse, instead. Yoda can
understand Yoda-speak, it comes natural to him. Yoda is not amongst the
readers of your code though, so please write in the common idiom :-)
This is okay for trunk with these things fixed. Thanks!
Segher
c_lvsl_direct;
You can align the ? and : just fine without it.
> + rtx op, addr, pat;
Don't declare such things early.
Okay for trunk with those things fixed. Thanks!
Segher
In general, any function that is unwieldily big should have pieces
factored out. A good time to do that is if you would be touching it
anyway (as a separate patch, before the other stuff most likely).
The patch is okay for trunk (w/ the changelog nit fixed :-) ) Thanks!
Segher
re it *will* go wrong, but that does not say much :-)
So, all VMX-style loads and stores need the &-16 .
We survived this for ages, and it is not like lve* is such a hotly used
builtin these days, so we'll survive things, but: put it on a to-do
list somewhere? :-)
> + /* Emit the lxvr*x insn. */
> + pat = GEN_FCN (icode) (tiscratch, addr);
(declare it here, "rtx pat", not much earlier)
Okay for trunk with whatever tidyings you feel you can make now, and
leave the rest for a later day. Thanks!
Segher
)
> +return NULL_RTX;
> + emit_insn (pat);
> +
>return target;
I'd put a blank line before that emit_insn. For dramatic tension, if
nothing else ;-) (It reads better imo).
Okay for trunk. Thanks!
Segher
You can say CRF here
("condition register field", a 4-bit thing), or just cc or CC maybe
("condition code"). A pet peeve, I know.
> + if (bif_is_endian (*bifaddr) && BYTES_BIG_ENDIAN)
"is_endian" should maybe be "is_bigendian" or something like that?
Okay for trunk with the changes you see fit at this time. Thanks!
Segher
On Tue, Oct 19, 2021 at 04:43:40PM +0200, Martin Liška wrote:
> On 10/19/21 16:23, Segher Boessenkool wrote:
> >On Fri, Oct 15, 2021 at 05:24:32PM +0200, Martin Liška wrote:
> >>On 10/14/21 17:10, Bill Schmidt via Gcc-patches wrote:
> >>>Looks like you g
; > Ok for trunk?
>
> OK.
If we really want to require such a new version of DejaGnu (most
machines I use have 1.5.1 or older), can we include it with GCC please?
Segher
On Thu, Nov 04, 2021 at 01:22:24PM +0100, Martin Liška wrote:
> On 11/4/21 12:55, Segher Boessenkool wrote:
> >On Fri, Oct 29, 2021 at 09:32:21AM +0200, Richard Biener via Gcc-patches
> >wrote:
> >>On Fri, Oct 29, 2021 at 2:42 AM Bernhard Reutner-Fischer vi
NUSED please.
Okay for trunk with those trivialities fixed. Thanks!
Segher
in_decls[RS6000_BUILTIN_MFFS]);
> + tree mtfsf
> += (new_builtins_are_live
> + ? rs6000_builtin_decls_x[RS6000_BIF_MTFSF]
> + : rs6000_builtin_decls[RS6000_BUILTIN_MTFSF]);
>tree call_mffs = build_call_expr (mffs, 0);
Same here.
Okay for trunk with that fixed. Thanks!
Segher
fprintf (stderr, "); %s [%4d]\n", attr_string, (int)code);
> +}
(space after cast)
>
> static const struct builtin_compatibility bdesc_compat[] =
> @@ -16097,6 +16209,67 @@ rs6000_init_builtins (void)
>/* Execute the autogenerated initialization code for builtins. */
>rs6000_init_generated_builtins ();
>
> + if (TARGET_DEBUG_BUILTIN)
> + {
(misindent)
> + if (e == ENB_P10_64 && (!TARGET_POWER10 || !TARGET_POWERPC64))
if (e == ENB_P10_64 && !(TARGET_POWER10 && TARGET_POWERPC64))
It even is shorter in this case ;-)
> + if (TARGET_DEBUG_BUILTIN)
> +fprintf (stderr, "%s __builtin_altivec_mask_for_load (%s); [%4d]\n",
> + rs6000_debug_type (TREE_TYPE (v16qi_ftype_pcvoid)),
> + rs6000_debug_type (TREE_VALUE
> + (TYPE_ARG_TYPES (v16qi_ftype_pcvoid))),
Never start a line with a paren from a function call. Often using an
extra variable is the best solution?
Okay for trunk with those things touched up. Thanks!
Segher
testcase to check this?
Okay for trunk. Thanks!
Segher
ot;int new_builtins_are_live = 1;\n\n");
>
>fprintf (init_file, "tree rs6000_builtin_decls_x[RS6000_OVLD_MAX];\n\n");
... and everything still works after this? Congrats!
Okay for trunk. Thanks!
Segher
hort
> *arg1_p,
>vector unsigned short arg_2 = *arg2_p;
>
>return __builtin_vec_vcmpnez_p (__CR6_LT, arg_1, arg_2);
> - /* { dg-error "'__builtin_altivec_vcmpnezh_p' requires the '-mcpu=power9'
> option" "" { target *-*-* } .-1 } */
> + /* { dg-error "'__builtin_altivec_vcmpnezh_p' requires the
> '-mpower9-vector' option" "" { target *-*-* } .-1 } */
> }
Hrm. People should not use the -mpower9-vector option (except implied
by -mcpu=power9, without vectors disabled). How hard is it to give a
better error message here?
The obvious bugfixes independent of this series are of course okay for
trunk, as separate patches, now. But some more work is needed
elsewhere.
Segher
t; + /* Allocate some buffers. */
> + for (int i = 0; i < MAXLINES; i++)
> +lines[i] = (char *) malloc (LINELEN);
C++ forces such unsightly casts, sigh. Well there are worse things.
Some certain operator comes to mind.
Thanks for this cleanup! In the new builtin definitions lines are much
shorter than before, but a few got really long anyway :-)
Okay for trunk. Thanks!
Segher
f cleanups I haven't done, but I made note in the code
> where these are needed.
I did not approve the testsuite one, it needs more work?
Segher
stop. It's "toolchain".
The patch is okay for trunk. Thanks! Do you need backports as well?
Those are fine as well :-)
Segher
cmpb (a, b); /* { dg-error "'__builtin_cmpb' is not
> supported in this compiler configuration" } */
> + return __builtin_cmpb (a, b); /* { dg-error "'__builtin_p6_cmpb' is
> not supported in 32-bit mode" } */
> }
The original spelling is the correct one?
Segher
tion says to use pc-relative processing, no matter if -mcpu=power10 is
used or not. For example, it will work fine with later CPUs as well.
So maybe this should just delete from after "addressing" to the end of
that line? It already says what the prerequisites are, on the very next
line :-)
Segher
ther than adding a previous prototype for
> ppc_backchain_fallback.
>
> Bootstrapped/regtested on powerpc64le-linux and powerpc64-linux (the latter
> with -m32/-m64 testing), ok for trunk?
Yes please. Thanks!
Segher
> 2021-11-09 Jakub Jelinek
>
> * co
-mno-mma
> @opindex mmma
> @opindex mno-mma
> -Generate (do not generate) the MMA instructions when the option
> -@option{-mcpu=future} is used.
> +Generate (do not generate) the MMA instructions. The @option{-mma}
> +option requires that the option @option{-mcpu=power10} (or later
> +@var{cpu_type}) is enabled.
(once more)
Okay for trunk with those changes. Thanks!
Segher
2021-11-10 Lucas A. M. Magalhães
>
> gcc/
> * config.gcc (powerpc*-*-*): Remove -rpath from
> --with-advance-toochain
I fixed the title and this last line, and pushed it to trunk. Thanks!
Segher
On Tue, Nov 09, 2021 at 04:03:55PM -0300, Lucas A. M. Magalhaes wrote:
> Quoting Segher Boessenkool (2021-11-09 11:19:58)
> > On Tue, Nov 09, 2021 at 10:39:46AM -0300, Lucas A. M. Magalhaes wrote:
> > > Ping.
> >
> > I did not get the original, and neither did the
On Wed, Nov 10, 2021 at 03:28:18PM -0600, Bill Schmidt wrote:
> On 11/10/21 2:33 AM, Segher Boessenkool wrote:
> > On Tue, Nov 09, 2021 at 03:46:54PM -0600, Bill Schmidt wrote:
> >>* config/rs6000/rs6000-builtin-new.def (CMPB): Flag as no32bit.
> >>(BPERMD): Flag
rrent = current->backchain;
Like you did here :-)
Do you have a testcase (that failed without this, but now doesn't)?
Looks okay, but please update and resend.
Segher
the backtrace and return.
> * unwind.inc (_Unwind_ForcedUnwind_Phase2): Treat _URC_NORMAL_STOP.
Committed, thanks! Please note the changelog formatting fixes I had
to do, for later patches :-)
Segher
t; Save
> Analyze and remove doubleword swaps from VSX computations.
>
> munroll-only-small-loops
> -Target Undocumented Var(unroll_only_small_loops) Init(0) Save
> +Target Undocumented Var(unroll_only_small_loops) Init(0) Save
> EnabledBy(funroll-loops)
You used format=flowed it seems? Don't. Patches are mangled with it :-(
Segher
On Fri, Nov 12, 2021 at 03:34:17PM +0100, Martin Liška wrote:
> On 11/11/21 18:52, Segher Boessenkool wrote:
> >You forgot to send the commit message though?
>
> No, the patch is simple so I didn't write any message (except commit title).
How is a maintainer supposed to kn
an just write this as {\mxxlor \d+,44,44\M} etc., that will be
simplest I think.
Okay for trunk with comments added near the earlyclobber, and the RE
improved. Also fine for 11 after some burn-in. Thanks!
Segher
Hi!
On Sun, Nov 14, 2021 at 08:17:41AM -0600, Bill Schmidt wrote:
> On 11/11/21 10:50 AM, Bill Schmidt wrote:
> > On 11/11/21 7:11 AM, Segher Boessenkool wrote:
> >> void f(long x) { __builtin_set_texasr(x); }
> >>
> >> built with -m32 -mpowerpc64 gives (i
f course it is not, and we can :-)
Some examples of how this improves generated code, or even some
benchmark results, would be good to have.
Also, how about something like
#define PROMOTE_MODE(MODE,UNSIGNEDP,TYPE) \
if (GET_MODE_CLASS (MODE) == MODE_INT \
&& GET_MODE_SIZE (MODE) < 4) \
(MODE) = SImode;
(that is, promoting modes smaller than SImode to SImode). How does that
compare?
Thanks!
Segher
On Wed, May 19, 2021 at 10:15:49AM +0200, Richard Biener wrote:
> On Wed, May 19, 2021 at 8:20 AM Kewen.Lin wrote:
> "weight_factor" is kind-of double-speak
"Weighting factor" (with -ing) is a standard term actually. (But
cost_factor of course is better and avoids all that :-) )
Segher
112-bit fraction (and a leading one).
The most significant of the two DP numbers is the whole rounded to DP.
The actual precision varies, it depends on various factors :-/
Segher
>integer(16), volatile :: m
>x = 2 / epsilon (x)
>y = 2 / epsilon (y)
>m = nint (x, kind
le, fused_arith_logical
is not for an arith insn fused with a logical insn, like most others are
patterned like.
Oh, and it doesn't hurt to use more lines here, if you can group things
better that would help. And of course you can use whitespace before
names here (you cannot tell from existing entries, but :-) )
Okay for trunk, with or without such improvements. Thanks!
Segher
t disable it
there -- if we do that unnecessarily all the time, much tooo little is
tested on darwin.
Okay for trunk, and a backport to 11 later. Thanks! And the previous
patch is fine for backport as well of course.
Segher
gt; +++ b/gcc/testsuite/gcc.target/powerpc/fusion-p10-logadd.c
> @@ -0,0 +1,98 @@
> +/* { dg-do compile { target { powerpc*-*-* } } } */
> +/* { dg-skip-if "" { powerpc*-*-darwin* } } */
Same issues here as in the previous patch.
Other than those things, okay for trunk and backport to 11. Thanks!
Segher
uld make the lines not wrap easy enough ;-) (Not that it matters of
course, this is a testcase, heh.)
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/fusion-p10-ldcmpi.c
> @@ -0,0 +1,66 @@
> +/* { dg-do compile { target { powerpc*-*-* } } } */
> +/* { dg-skip-if "" { powerpc*-*-darwin* } } */
And one more.
Okay for trunk and backport to 11 with those things looked at. Thanks!
Segher
Hi!
On Wed, May 19, 2021 at 08:35:26PM +0200, Tobias Burnus wrote:
> On 19.05.21 17:15, Segher Boessenkool wrote:
> >>real(16) :: y ! 128bit REAL
> >>integer(16), parameter :: k2 = nint (2 / epsilon (y), kind(k2))
> >>
8))
> +mode = TARGET_32BIT ? SImode : DImode;
> ~
> return mode;
> }
This is fine (of course). Okay for trunk. Thanks!
Segher
Hi!
On Thu, May 20, 2021 at 04:29:07PM +0800, HAO CHEN GUI wrote:
> On 19/5/2021 下午 9:20, Segher Boessenkool wrote:
> >On Wed, May 19, 2021 at 04:36:00PM +0800, HAO CHEN GUI wrote:
> >>-/* Define this macro if it is advisable to hold scalars in registers
> >>- in a wi
number of built-ins used "long" for DImode types, which would
> break these for 32-bit. I changed those arguments and return values
> to "long long" to avoid such problems, when those built-ins were not
> restricted to 64-bit mode already. There aren't many such cases.
You can do this for 64-bit-only builtins as well -- the actual argument
type is never visible (to the user), and everything becomes modes early.
Segher
These are identified as "./.h". */
> +extern const char** build_headers;
extern const char **build_headers;
(I hope someone who can approve this will review it.)
Segher
t any good ideas
> from MAINTAINERS. If you know of a good reviewer candidate, please CC
> them.
Richard is listed as the "gen* on machine desc" maintainer, that might
be the closest to this. cc:ed.
Segher
ivec_abs_v8hi (vss);
> +ABS_V8HI absv8hi2 {}
> +
> + Here "vsc" and "vss" are shorthand for "vector signed char" and
> + "vector signed short" to shorten line lengths and improve readability.
I like :-)
Okay for trunk. Thanks!
Segher
r, I hope
you realise :-)
Okay for trunk. Thanks!
Segher
and those are the only hosts we
support. Still icky :-)
If you just leave off the initialisation, it will be initialised to 0,
which is exactly the same problem of course, just less explicit.
This pointer is not static btw? Should it be?
Okay for trunk with a little changelog massaging. Thanks!
Segher
On Wed, May 19, 2021 at 09:39:30PM +0930, Alan Modra wrote:
> On Tue, May 18, 2021 at 05:48:40AM -0500, Segher Boessenkool wrote:
> > I wrote a bit later:
> >
> > > > Can you make this less hacky please? Changing the generic code is just
> > > > fine a
hem in, and that is plenty?
> + if (lastpos < pos)
> +return 0;
> +
> + char *buf = (char *) malloc (lastpos - pos + 2);
> + memcpy (buf, &linebuf[pos], lastpos - pos + 1);
> + buf[lastpos - pos + 1] = '\0';
> +
> + pos = lastpos + 1;
> + return buf;
> +}
Are there no utility routines you can use? It would be useful to have
something that all gen* can use (something less bare than what there is
now...)
Segher
this simplifies the parsing
> + significantly and is hopefully forgivable.
> +
> + Return 1 for success, else 0. */
> +static int
> +match_const_restriction (typeinfo *typedata)
> +{
> + return 1;
> +}
And this.
Okay for trunk with the trivialities fixed. Thanks!
Segher
On Tue, Apr 27, 2021 at 10:32:43AM -0500, Bill Schmidt via Gcc-patches wrote:
Oh, hrm, I deleted it all? I guess there was nothing to complain about
^W^Wcomment on then! Okay for trunk. Thanks!
Segher
(linebuf[pos] == '[');
Can you factor this please? The three cases do exactly the same? And
if not, it would be much clearer if you make the difference explicit.
Pass the two '<', '>' as arguments, and you can use that to
differentiate then, even.
Okay for trunk either way. Thanks!
Segher
need this in the header? You could just say
enum rbt_color;
and nothing more?
Okay for trunk, whatever you decide to do for these. Thanks!
Segher
Hi!
On Fri, May 21, 2021 at 03:56:09PM -0500, Bill Schmidt wrote:
> On 5/21/21 1:51 PM, Segher Boessenkool wrote:
> >>+/* Exit codes for the shell. */
> >>+enum exit_codes {
> >>+ EC_INTERR
> >>+};
> >Please define this with some specified value
which it
should if the insn is a single_set (likely, but Joern didn't show the
actual insns, so we don't know), or simple_move_p isn't true. And the
latter means that register_move_cost isn't 2, which all trivial moves
should have.
Does that help?
Segher
-memory situation.
If this was in GCC itself we would get a helpful ICE as-is. Since this
is in a generator file we can assume whoever debugs this knows how to
fire up GDB for it, so it is fine as well.
There are thousands of ways a developer can crash the generators by
giving bad inputs. An out-of-memory condition is not likely at all,
compared to that.
Segher
s that niter analysis cannot handle ...
As long as it doesn't do that for signed loop counters, because that
would be a waste -- ever executing such code is UB, so vectorising it
will only cost extra insns (usually).
Segher
mi-rlnm.c
> @@ -62,6 +62,6 @@ rlnm_test_2 (vector unsigned long long x, vector unsigned
> long long y,
> -/* { dg-final { scan-assembler-times "xxlor" 3 } } */
> +/* { dg-final { scan-assembler-times "xxlor" 5 } } */
This was expected, right?
Okay for trunk, and backports after a while. Thanks!
Segher
imised away later.
That would be quite hard to do in fact, and if it is handled in Gimple
all will be fine, and it should be much easier to do in Gimple.
Can you open a PR please?
Segher
ively trivial to move
to the modern world: two expanders, two insns; and only cmp, cbranch,
cstore for that matter; anyone who knows cr16 at all can probably do it.
But that is not me, I do not know how to *test* cr16 at all.
Segher
Hi!
On Fri, May 21, 2021 at 02:45:18PM -0500, Peter Bergner wrote:
> Getting back to this now that trunk is open again...
>
> On 3/31/21 2:17 PM, Segher Boessenkool wrote:
> > On Tue, Mar 30, 2021 at 06:49:29PM -0500, Peter Bergner wrote:
> >> The mma_assemble_input_op
RECISION_TFmode)
Please propose that as separate patch, and/or open a PR for it. Having
everything in one mail thread might be easiest for you, but it isn't for
everyone else ;-)
> What target maintainers thing about it?
That we need a lot more background: what do you want to do, and why?
Segher
actually reply to it!
I'll see if I can fix it up this time.
Segher
mode, gen_rtx_VEC_DUPLICATE (mode, XEXP (op, 0)));
> + break;
If it isn't a canonicalisation you need to simplify the result, and then
only do it if it does in fact simplify. You risk "simplification" loops
if you don't.
Segher
We haven't had Sender: for a while now. Use the standard List-Id:
header in its place.
Committed.
Segher
---
htdocs/lists.html | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/htdocs/lists.html b/htdocs/lists.html
index 42a44ab83d9b..4ac5d5a84cd1 100644
--- a/h
) == const16_rtx)
and things like that, since all const_int in that range are unique. We
already do for -1, 0, 1, 2, but we could for everything.
2021-06-01 Segher Boessenkool
* rtl.h (constm64_rtx, ..., constm2_rtx): New.
(const3_rtx, ..., const64_rtx): New.
doc/
* rtl.texi
On Tue, Jun 01, 2021 at 03:34:50PM -0500, Pat Haugen wrote:
> Make sure link reg save MEM has frame alias set, to match other link reg
> save/restore code.
Okay for trunk and any backports (please do at least GCC 11). Thanks!
Segher
ractice in procmailrcs, although not necessarily a good idea :-)
Thanks to Andreas Schwab for noticing. Committed.
Segher
---
htdocs/lists.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/htdocs/lists.html b/htdocs/lists.html
index 4ac5d5a84cd1..e9636198b732 100644
--
ELFv2.
Segher
dress will then refer to that pseudo. So I don't see any
> connection between the prolog save code and __builtin_return_address.
That is for __builtin_return_address(0), the simple (and always working)
one. It is harder for non-zero arguments (although I don't see why
those would not work, even with inlining).
Segher
On Wed, Jun 02, 2021 at 10:44:34AM +0200, Gerald Pfeifer wrote:
> On Tue, 1 Jun 2021, Segher Boessenkool wrote:
> > We haven't had Sender: for a while now.
>
> "a while now" was about four(?) hours when you sent that yesterday. :-)
Ah, I thought it was since we
On Wed, Jun 02, 2021 at 09:17:20AM +0200, Gerald Pfeifer wrote:
> On Tue, 1 Jun 2021, Segher Boessenkool wrote:
> > Brown paper bag time. The List-Id: should look like a hostname, not
> > like an email address. Somehow I put in an at-sign when changing my
> > gcc-patches exa
On Wed, Jun 02, 2021 at 10:25:34AM +0200, Andreas Schwab wrote:
> On Jun 01 2021, Segher Boessenkool wrote:
> > -* ^List-Id: .*<.*@gcc.gnu.org>$
> > +* ^List-Id: .*<.*.gcc.gnu.org>$
>
> Shouldn't the < and > be mangled as < and >?
"It works fine for me!"
You are right of course.
Segher
al_p (trueop0, trueop1) && ! side_effects_p (op0))
return op0;
tem = simplify_associative_operation (code, mode, op0, op1);
if (tem)
return tem;
break;
(the stuff using "tem").
Hongtao, can we do something similar here? Does that work well? Please
try it out :-)
Segher
use -mno-regnames?
> +#ifndef __FLOAT128__
> +#error "-mfloat128 is not supported."
> +#endif
So this can be deleted as well.
Segher
Hi!
On Wed, Jun 02, 2021 at 06:07:28PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > Since times immemorial there has been const_int_rtx for all values from
> > -64 to 64, but only constm1_rtx..const2_rtx have been available for
> > convenient use. Change
pted
> before. Thanks for bringing this up! We have to update the
> documentation if people reach a consensus.
It will help if the error message tells you
If this is what you intended, write "1".
or similar. No more documentation is needed then :-)
Segher
define_insn_and_splits that have no "&&".
If we make that change permanently, that is all steps we ever need!
Very old backends use the same insn condition and split condition
sometimes still; it isn't hard to detect that as well, if that seems
prudent.
Segher
correctly for big endian (it needs to
walk from right to left for that). The construction of the return value
looks wrong as well.
Okay for trunk with that fixed. Thanks!
Segher
On Wed, Jun 02, 2021 at 05:13:16PM -0500, Paul A. Clarke wrote:
> + for (i = 0; i < NUM; i++)
> +src.s[i] = i * i - 68 * i + 1200;
Could you do tests with some identical elements as well? Because that
is where I think it fails on BE currently.
Segher
s6000/fusion.md: Regenerate input.
It is not the *input* you regenerated ;-) Just "Regenerate." is custom.
Segher
Hi!
On Thu, Jun 03, 2021 at 01:22:38PM +0800, Kewen.Lin wrote:
> on 2021/6/3 上午7:52, Segher Boessenkool wrote:
> >> - add a new "define_independent_insn_and_split" that has the
> >> current semantics of define_insn_and_split. This should be
> >> mecha
On Thu, Jun 03, 2021 at 03:00:44AM -0500, Segher Boessenkool wrote:
> On Thu, Jun 03, 2021 at 01:22:38PM +0800, Kewen.Lin wrote:
> The whole point of requiring the split condition to start with && is so
> it will become harder to mess things up (it will make the gen* code a
uld not be intuitive at all.
> IMO requiring the "&&" is baking in an alternative, less intuitive,
> interpretation.
But you want the exact same semantics, right? I do agree that the
syntax without "&&" looks nicer. It has many practical problems though,
so it is nice to aim for, but we cannot move there until we have all
existing machine descriptions fixed up first.
Segher
e-mode.c
> @@ -0,0 +1,13 @@
> +/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
Just
/* { dg-do compile { target lp64 } } */
because the rest is already implied by this being in gcc.target/powerpc .
The patch is okay for trunk. Thank you very much for finding this huge
performance gain!
Segher
ink: you need to
make sure nothing ever creates non-canonical code.
> Maybe we can add insn canonicalization for transforming (and (vect_duplicate
> (not A)) B) to
> (and (not (duplicate (not A)) B) instead of (vec_duplicate (not A)) to (not
> (vec_duplicate A))?
I don't understand what this means?
Segher
Hi!
On Thu, Jun 03, 2021 at 08:46:46AM +0800, Xionghu Luo wrote:
> On 2021/6/3 06:20, Segher Boessenkool wrote:
> > On Wed, Jun 02, 2021 at 03:19:32AM -0500, Xionghu Luo wrote:
> >> On P8LE, extra rot64+rot64 load or store instructions are generated
> >> in float128 to
th places.
Oh certainly, and we need that p8swaps pass on at least p8 anyway (but
perhaps we can allow TImode in vector regs on later cpus).
Segher
se %v2:V1TI
>
> Then followed split1 pass will still split it to due to no dse pass
> between to remove the memory operations on stack, remove the rotate
> in swap won't face such problem since it runs before dse and no split
> pass between them:
Sure, but none of that is the point. I asked if we did this for TImode
properly, and maybe we do, but:
>22: r126:V1TI=r125:KF#0<-<0x40
>23: [sfp:DI+r123:DI]=r126:V1TI<-<0x40
... this is V1TI mode.
Segher
1101 - 1200 of 6091 matches
Mail list logo
