On Sat, Jun 27, 2020 at 01:57:52AM -0400, Michael Meissner wrote:
> On Thu, Jun 25, 2020 at 11:52:50AM -0500, Segher Boessenkool wrote:
> > On Mon, Jun 01, 2020 at 03:53:37PM -0400, Michael Meissner wrote:
> > > Add tests for -mcpu=future that test the generation of PADDI (an
Hi Kewen,
On Mon, Jun 29, 2020 at 02:32:47PM +0800, Kewen.Lin wrote:
> V5: Like V4.
It is still okay for trunk, like before :-)
Segher
l
> +++ b/gcc/testsuite/gcc.target/powerpc/prefix-no-update.c
> @@ -0,0 +1,51 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target powerpc_prefixed_addr } */
> +/* { dg-require-effective-target lp64 } */
> +/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
For this testcase, I have no idea at all why you want lp64?
Thanks,
Segher
reg (DImode, tmp_df, DFmode, 0);
> > +rtx tmp_di_2 = gen_reg_rtx (DImode);
> > +emit_insn (gen_anddi3 (tmp_di_2, tmp_di, GEN_INT (0x3LL)));
Just GEN_INT (3) will do fine.
Another question. How do these builtins prevent other FP insns from
being moved (or optimised) "over" them?
Segher
On Mon, Jun 29, 2020 at 02:29:54PM -0700, Carl Love wrote:
> Segher:
>
> On Thu, 2020-06-25 at 17:39 -0500, Segher Boessenkool wrote:
> > > +;; Return 1 if op is a constant 32-bit floating point value
> > > +(define_predicate "f32bit_const_operand&quo
On Mon, Jun 29, 2020 at 11:45:41PM +0200, Marc Glisse wrote:
> On Mon, 29 Jun 2020, Segher Boessenkool wrote:
>
> >Another question. How do these builtins prevent other FP insns from
> >being moved (or optimised) "over" them?
>
> At the GIMPLE level they do
o "__int128" is not
> suported. I'll be adding some form of require-target int128 to clear
> that up.
Yes, that is a generic problem, not specific to rs6000. It would be
very nice if that was fixed some day!
Segher
VEC_OVERLOAD_3
> entry.
No line break before (vmsumudm) please.
> * config/rs6000/rs6000-call.c (altivec_overloaded_builtins):
> Add entries for ALTIVEC_BUILTIN_VMSUMUDM variants of vec_msum.
Tha patch is okay for trunk with that (and some int128 selector in the
testcases that need one). Thanks!
Segher
Hi!
On Tue, Jun 30, 2020 at 01:58:50AM -0400, Michael Meissner wrote:
> On Mon, Jun 29, 2020 at 01:42:56PM -0500, Segher Boessenkool wrote:
> > On Mon, Jun 29, 2020 at 02:23:22PM -0400, Michael Meissner wrote:
> > > +/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
>
Hi!
On Mon, Jun 29, 2020 at 03:31:48PM -0700, Carl Love wrote:
> On Mon, 2020-06-29 at 16:58 -0500, Segher Boessenkool wrote:
> > On Mon, Jun 29, 2020 at 02:29:54PM -0700, Carl Love wrote:
> > > Segher:
> > >
> > > On Thu, 2020-06-25 at 17:39 -0500, Segher Boe
t;vecsimple")])
vsx_register_operand together with a "v" constraint is curious, btw.
It is used in a few more places, and it probably works, but would
altivec_register_operand be better?
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/vsx_mask-count-runnable.c
> @@ -0,0 +1,149 @@
> +/* { dg-do run } */
> +/* { dg-options "-mcpu=future -O2 -save-temps" } */
> +/* { dg-require-effective-target powerpc_future_hw } */
Drop the -save-temps? (Same in the other tests.)
Looks good otherwise.
Segher
for?
Okay for trunk with maybe that taken out. Thanks! Also okay for 10 if
you want a backport?
Segher
instead.
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/bswap-brh.c
> @@ -0,0 +1,12 @@
> +/* { dg-do compile { target { powerpc*-*-* } } } */
powerpc*-*-* is default. Don't use it here.
> +/* This tests whether GCC generates the ISA 3.1 16-bit byte swap
> + instruction BRH. */
"whether GCC generates "brh" to implement 16-bit byte swap" or such...
(the instruction swaps every pair of bytes).
Okay for trunk with those things fixed. Thanks!
Segher
emit_fp_min_max_insn (rtx dest, rtx op, rtx true_cond, rtx false_cond)
Please change the name (and the comment) to make it clear this function
does *not* always emit code, and returns a boolean (an int, maybe change
that too?) saying whether it did do the deed.
Segher
get power10_ok } */
> +/* { dg-options "-mdejagnu-cpu=power10 -O2 -ffast-math" } */
> +/* { dg-final { scan-assembler-not "xscmpuqp" } } */
> +/* { dg-final { scan-assembler "xscmpeqqp" } } */
> +/* { dg-final { scan-assembler "xscmpgtqp" } } */
> +/* { dg-final { scan-assembler "xscmpgeqp" } } */
> +/* { dg-final { scan-assembler "xsmaxcqp" } } */
> +/* { dg-final { scan-assembler "xsmincqp" } } */
> +/* { dg-final { scan-assembler "xxsel" } } */
Please use \m \M.
Segher
scan-assembler-not {\mxxpermdi\M} } } */
There are other ways to write the stores (older insns, and prefixed
insns, for example). xxpermdi has many extenden mnemonics (and we
actually use those, they improve readability quite a bit).
It helps if you also test what insns *should* be there, the testcase
will not so easily silently pass (while the generated code is not what
it wants) that way.
Segher
her hot functions, and the swing between
> different functions is larger than this difference; to be dealt
> with separately.
>
> Tested cris-elf, x86_64-linux, powerpc64le-linux, 2/3 through
> aarch64-linux (unexpectedly slow).
>
> Ok to commit?
No, sorry.
One thing that could work is allowing (unused) clobbers of fixed
registers (like you have here), or maybe some hook is needed to say this
register is like a flags register, or similar. That should work for you,
and not regress other targets, maybe even help a little? We'll see.
Thanks,
Segher
xscvspdpn_directmove (op0, op0));
DONE;
}
else
FAIL;
}
[(set_attr "length" "12,*,*")
(set_attr "type" "vecfloat,mffgpr,*")
(set_attr "isa" "p8v,p8v,*")])
I wonder what will happen if you actually do FAIL here... There then is
no insn alternative that can match, so we ICE? In that case, just leave
out the whole FAIL thing, it is useless? You can do a gcc_assert if you
want to check something.
Oh, and maybe you only want to handle GPRs here, not VSRs? So just the
"r", not the "wa" at all? What code would it generate for vector regs?
Lots of questions, sorry!
Segher
> +OPAQUE_MODE (XO, 64); /* instead of PXI */
Those comments already make no sense, because those types occur nowhere
anymore! Just say what they *are* used for? __vector_pair and
__vector_quad.
> @@ -16434,8 +16433,11 @@ rs6000_split_multireg_move (rtx dst, rtx src)
>if (GET_CODE (src) == UNSPEC)
> {
> gcc_assert (REG_P (dst)
> + && ((GET_MODE (src) == XOmode
> +&& FP_REGNO_P (REGNO (dst)))
> + || (GET_MODE (src) == OOmode
> + && VSX_REGNO_P (REGNO (dst
> + && XINT (src, 1) == UNSPEC_MMA_ASSEMBLE);
You can write that as separate statements much more readable?
gcc_assert (XINT (src, 1) == UNSPEC_MMA_ASSEMBLE);
gcc_assert (REG_P (dst));
if (GET_MODE (src) == XOmode)
gcc_assert (FP_REGNO_P (REGNO (dst)));
if (GET_MODE (src) == OOmode)
gcc_assert (VSX_REGNO_P (REGNO (dst)));
> + if ( GET_MODE (src) == XOmode )
(stray spaces)
> + {
> + /* We are writing an accumulator register, so we have to
> + prime it after we've written it. */
> + emit_insn (gen_mma_xxmtacc (dst, dst));
> + }
You don't need a block around single insns (and in GCC we do not usually
do that for comments either -- the comment should usually go before the
"if" anyway, like here :-) )
Lots of little stuff, but also a few more serious things. Sorry :-)
Segher
0;
return general_operand (op, mode);
}
(The SFmode thing and subregs-of-mem are complifying things, just to
keep things interesting.)
We need to allow subregs of reg pretty much always, for reinterpret_cast
like things (say, changing one vector mode to another).
Segher
or trunk after the rs6000 "opaque" patch goes in. Thanks!
Segher
27;t see where we'd copy from that new target
> > to the original desired target.? For some expanders the caller would
> > handle that, but I don't see how that's possible for this one without
> > the caller digging into the generated RTL to determine that
> > expand_builtin_fegetround put the result somewhere other than TARGET and
> > thus a copy is needed.
> >
> > That may be what Richi is worried about.
>
> I know we've added missing
>
> if (!rtx_equal_p (target, ops[0].value))
> emit_move_insn (target, ops[0].value);
>
> to several expanders (using expand_insn rather than manual
> GEN_FCN (icode) calls).
We can handle the constants issue similarly to what we do for
__builtin_fpclassify, too.
Segher
in the source code, with a comment where you require it!)
Segher
break? Nasty.
Of course such things aren't proper C (you *have to* include
if you use functions from there), but how often will code like this
happen in practice :-/
The patch is okay for trunk. Thanks!
Segher
00 is bigger,
and representable as double-double just as well? Or even
43feff80 should be.
Segher
On Wed, Nov 18, 2020 at 10:53:49PM +0100, Jakub Jelinek wrote:
> On Wed, Nov 18, 2020 at 03:43:20PM -0600, Segher Boessenkool wrote:
> > Hi!
> >
> > On Sun, Nov 15, 2020 at 12:17:47PM -0500, Michael Meissner wrote:
> > > --- a/gcc/testsuite/gcc.target/powerpc/pr701
On Thu, Nov 19, 2020 at 03:08:05AM -0500, Michael Meissner wrote:
> On Wed, Nov 18, 2020 at 04:29:09PM -0600, Segher Boessenkool wrote:
> > Mike, please add a comment, what number it represents? Okay for trunk
> > with that, thanks.
> >
> > (Should those not be d
On Wed, Nov 18, 2020 at 07:13:04PM -0600, Paul A. Clarke wrote:
> On Wed, Nov 18, 2020 at 04:29:09PM -0600, Segher Boessenkool wrote:
> > Mike, please add a comment, what number it represents? Okay for trunk
> > with that, thanks.
> >
> > (Should those not be d
ehind adding a PARAM to control this
> behavior? I'm not a big fan of exposing a lot of PARAMs for users to
> tune behavior (though I've made the same lapse in judgment myself). In
> my mind a PARAM is really more about controlling pathological behavior.
But we (Power) need very different tuning than what others apparently
need. It is similar to inlining, in that that also differs a lot
between archs how aggressively to do that optimally.
Segher
On Thu, Nov 19, 2020 at 12:53:27PM -0700, Jeff Law wrote:
> On 11/19/20 12:42 PM, Segher Boessenkool wrote:
> > On Thu, Nov 19, 2020 at 12:13:34PM -0700, Jeff Law wrote:
> >> On 8/31/20 9:33 PM, Jiufu Guo via Gcc-patches wrote:
> >>> guojiufu writes:
> >>&
> > + "TARGET_POWER10"
> > + "vmulld %0,%1,%2"
> > + [(set_attr "type" "vecsimple")])
>
> Similarly, the above 3 insns should have a "mul" instruction type.
The existing AltiVec vmul* are type "veccomplex", because that was the
execution pipe used on original AltiVec... This needs to be adapted as
well. Not sure what is best.
Segher
That is veccomplex?
> +Vector Integer Multiply-Divide-Modulo
Use "/" instead of "-" here? "-" normally is used for things like
"multiply-sum", not to mean "or".
> +For each integer value i from 0 to 3, do the following. The integer value in
> +word element i of a is multiplied by the integer value in word
> +element i of b. The high-order 32 bits of the 64-bit product are placed into
> +word element i of the vector returned.
I think you should quote the "i"? @code{i} or similar. I don't think
you need to mark up the digits, phew :-)
Please repost with those things fixed? Thanks!
Segher
s, not to block
having new ones which can be useful (while many of the existing ones are
not).
Or, we could accept that it is not really a problem at all. You seem to
have a strong opinion that it *is*, but I don't understand that; maybe
you can explain a bit more?
Thanks,
Segher
t choice) done in comparable way on
> multiple arches.
We cannot help with that on the cfarm, unless we get dedicated hardware
for such benchmarking (and I am not holding my breath for that, getting
good coverage at all is hard enough). So you probably need to get such
support for every arch separately, elsewhere :-/
Segher
On Fri, Nov 20, 2020 at 10:42:19AM -0500, Michael Meissner wrote:
> Power10: Add missing IEEE 128-bit XSCMP* built-in mappings.
Okay for trunk (and needed backports after waiting for possible
fallout). Thanks!
Segher
> 2020-11-18 Michael Meissner
>
> * config/rs6000/r
N_DISASSEMBLE_PAIR_INTERNAL)
> +&& (attr & RS6000_BTC_QUAD) == 0)
> attr_args--;
(surplus space right before the !)
Okay for trunk with those nits fixed. Thanks!
(The input_operand thing can be a follow-up patch; it *does* generate
correct code like this, just not always optimal).
Segher
me.
> Please retest and commit. Thanks!
It all makes sense, and is a nice improvement :-) But please mention it
in the release notes? No doubt people did use non-sensical flag
combinations, and they will be affected. Thanks!
Segher
On Sat, Nov 21, 2020 at 12:27:30AM -0500, Michael Meissner wrote:
> On Thu, Nov 19, 2020 at 08:03:02AM -0600, Segher Boessenkool wrote:
> > Sure -- I am suggesting to always define __IBM128_MAX__ and the like,
> > which then can be used to define LDBL_MAX, but also can be used
>
On Mon, Nov 23, 2020 at 08:10:49PM +0100, Jakub Jelinek wrote:
> On Mon, Nov 23, 2020 at 12:59:29PM -0600, Segher Boessenkool wrote:
> > On Sat, Nov 21, 2020 at 12:27:30AM -0500, Michael Meissner wrote:
> > > On Thu, Nov 19, 2020 at 08:03:02AM -0600, Segher Boessenkool wrote:
&g
"ppc_recip_hw" { set selected [check_ppc_recip_hw_available] }
> "ppc_cpu_supports_hw" { set selected
> [check_ppc_cpu_supports_hw_available] }
> "ppc_mma_hw" { set selected [check_ppc_mma_hw_available] }
Why this? It just defines aliases to the exact same name?
Segher
need a better explanation / justification for the patch.
What goes wrong without the patch? Is that to be expected? Etc.
You get less coverage than before after this patch (it will now only run
on systems that have double-double as long double).
Segher
* c-c++-common/dfp/convert-bfp-11.c: Require IBM 128-bit long
> double.
Okay for trunk (and backports later). Thanks!
Segher
Hi!
Sorry this took so long.
On Thu, Oct 15, 2020 at 04:46:01PM +0800, HAO CHEN GUI wrote:
> On 29/9/2020 上午 6:46, Segher Boessenkool wrote:
> >[ Please do not insert patches into discussions ]
So, please send new patches as a new thread. This makes it much easier
to handle. If yo
building the IBM 128-bit long double support.
It's not clear to me what error disabling setting it for the static
library avoids? Not that it *hurts* of course. Do you have an example
for this?
Anyway, okay for trunk (and backports later). Thanks!
Segher
; -}
But this *does* use long double. So this testcase is valid, and you
should not delete it.
Instead, it points out you have a deficiency in the code, one that used
to be hidden by how you used moves to set the attribute.
Same for the other testcases you delete.
Segher
unk that overload the 'c' output modifier.
Most do it for something with condition codes (or comparisons). This is
a well-established convention, confusing or not :-)
(I have nothing against the patch of course.)
Segher
On Fri, Nov 20, 2020 at 03:36:24AM +, Maciej W. Rozycki wrote:
> Use a double colon to introduce the comments like elsewhere throughout
> the VAX machine description.
It's a double semicolon, so kind of a single colon ;-)
Segher
written on the normal path, and
they are either or not written when it throws.
The difference with your situation is in that case you specify all
labels the code could jump to, and in your case you don't. Maybe
just one less colon could make the distinction? (asm goto has four
colons, other asm has at most three).
Segher
Hi!
On Tue, Nov 24, 2020 at 11:55:23AM +0100, Ulrich Weigand wrote:
> On Sat, Nov 21, 2020 at 01:57:32PM -0600, Segher Boessenkool wrote:
> > It all makes sense, and is a nice improvement :-) But please mention it
> > in the release notes? No doubt people did use no
On Sat, Oct 10, 2020 at 03:08:22AM -0500, Xionghu Luo wrote:
> rs6000_expand_vector_set could accept insert either to constant position
> or variable position, so change the operand to reg_or_cint_operand.
This is okay for trunk. Thank you!
Segher
> 2020-10-10 Xi
erify this, tricky bit-fiddling!
But the code that generates this is easier to read :-)
> +/* Insert VAL into IDX of TARGET, VAL size is same of the vector element, IDX
> + is variable and also counts by vector element size. */
"Set vector element IDX of TARGET to VAL. IDX is not a constant
integer."?
Okay for trunk (with an improved comment). Thanks!
Segher
> I'll still need to look into the language-specific handling of the
> excess precision setting to make sure this works for all languages.
At least C uses "standard" (instead of "fast") for the strict ISO C
dialects.
Segher
On Tue, Nov 24, 2020 at 04:44:19PM -0500, Michael Meissner wrote:
> On Mon, Nov 23, 2020 at 02:28:57PM -0600, Segher Boessenkool wrote:
> > On Sat, Nov 21, 2020 at 12:33:52AM -0500, Michael Meissner wrote:
> > > +# See if the target is a powerpc with the long double format that u
vector_usage, 1);
else
SET_OPTION_IF_UNSET (&global_options, &global_options_set,
param_vect_partial_vector_usage, 0);
Okay for trunk with such a comment (before the "if"). Thanks!
Segher
ize can matter). But, the
definitions of and now say
;; What data size does this instruction work on?
;; This is used for insert, mul and others as necessary.
(define_attr "size" "8,16,32,64,128" (const_string "32"))
and
;; How many bits in this mode?
(define_mode_attr bits [(QI "8") (HI "16") (SI "32") (DI "64")
(SF "32") (DF "64")])
so those need a bit of update as well then :-)
Segher
us is to just
add HTM to the power8, power9, and powerpc64le entries.
Segher
rget_enable &
> OPTION_MASK_HTM))
> + && !(processor_target_table[tune_index].target_enable
> +& OPTION_MASK_CRYPTO))
> rs6000_isa_flags |= ~rs6000_isa_flags_explicit &
> OPTION_MASK_STRICT_ALIGN;
But not this. Not all ISA 2.07 processors implement the crypto
category. You could use OPTION_MASK_DIRECT_MOVE, instead?
Okay for trunk with that change (if that works ;-) ) Thanks!
Segher
ing expected symbols.
One less underscore.
> libstdc++-v3/ChangeLog:
>
> * Makefile.in:
> * config.h.in:
(etc.) Something missing here?
All the actual patch looks fine to me, but that doesn't say much :-)
Segher
u with the additional task - the patch
> is OK as it is. I was just thinking out loud, as I remembered that
> changing bt patterns to combine splitter regressed one testcase. IIRC
> combination of two insns blocked better combination of three insns, or
> something like that.
>
> > To turn those pre-reload define_insn_and_splits I'm afraid we'd indeed
> > need combiner's changes, so that would need to be discussed with Segher
> > first.
>
> Yes, that is the long-term plan. Segher CC'd.
A splitter can *already* split to only one insn.
Segher
On Fri, Dec 04, 2020 at 07:32:43PM +0100, Uros Bizjak wrote:
> On Fri, Dec 4, 2020 at 7:26 PM Segher Boessenkool
> wrote:
> > A splitter can *already* split to only one insn.
>
> Oh... brown paper bag time... I really don't know where and when I
> pick that info, sinc
Hi!
On Mon, Dec 07, 2020 at 03:27:14PM +0100, Uros Bizjak wrote:
> On Fri, Dec 4, 2020 at 7:26 PM Segher Boessenkool
> wrote:
> > A splitter can *already* split to only one insn.
>
> Unfortunately, the attached patch with the following testcase:
>
> --cut here--
On Mon, Dec 07, 2020 at 04:40:39PM +0100, Jakub Jelinek wrote:
> On Mon, Dec 07, 2020 at 09:28:19AM -0600, Segher Boessenkool wrote:
> > I see. We could also allow this for 2->2 combinations (w/ the same
> > restrictions we do for other 2->2 combinations, but that p
On Mon, Oct 12, 2020 at 01:24:44PM +0100, Richard Sandiford wrote:
> Martin Sebor via Gcc-patches writes:
> > On 10/4/20 10:51 AM, H.J. Lu via Gcc-patches wrote:
> >> On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
> >> wrote:
> >>>
> &g
it does take time if I have to
> reproduce the problem manually before reporting.
Yes, and it is *easier* to reproduce for you than for other people!
> > *Actually* following up to the patch mail could be useful (but you can
> > than just point to the bugzilla). Sending spam to gcc-patches@ is not
> > useful for most users of the list.
^^^ Still my main point.
Segher
On Mon, Oct 12, 2020 at 05:19:58PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Fri, Oct 09, 2020 at 09:38:09AM +0100, Alex Coplan wrote:
> >> Hi Segher,
> >>
> >> On 08/10/2020 15:20, Segher Boessenkool wrote:
> >> > On Th
ll, maybe we
have to write it out, not everything is best explained in few words?
Segher
mp; p9vector_hw } } } }
> */
Why only on Linux? (And everything in gcc.target/powerpc/ is powerpc*
always, so could just be *-*-linux*).
Looks good otherwise.
Segher
define vec_rlnm(a,b,c) (__builtin_vec_rlnm((a),((b)<<8)|(c)))
> #define vec_rsqrt __builtin_vec_rsqrt
> #define vec_rsqrte __builtin_vec_rsqrte
> #define vec_signed __builtin_vec_vsigned
That patch is fine of course, thanks! Is there some testcase that trips
over the old definition? That would have been good to have.
Segher
uot; } */
> > +/* { dg-require-effective-target power10_hw } */
> > +/* { dg-require-effective-target ppc_native_128bit } */
>
> I don't see any other uses of the target option for ppc_native_128bit
> in my tree ?
I don't see where it is defined, even?
Segher
ned
> with a few other patches, orthogonal to what is proposed here and
> which I'll post shortly).
>
> Same ChangeLog. Patch hopefully quotable if needed now.
It is, thank you!
The patch looks fine to me now. Not that you need my approval :-)
Segher
Hi!
On Tue, Oct 13, 2020 at 11:58:11AM +0200, Christophe Lyon wrote:
> On Mon, 12 Oct 2020 at 18:43, Segher Boessenkool
> wrote:
> >
> > On Mon, Oct 12, 2020 at 03:26:38PM +0200, Christophe Lyon wrote:
> > > That's why I kept the reporting part manual on my side:
* gcc.c-torture/execute/pr97386-1.c: New test.
> * gcc.c-torture/execute/pr97386-2.c: New test.
The patch is fine, okay for trunk, thanks!
Segher
On Tue, Oct 13, 2020 at 07:03:15PM +0200, Jakub Jelinek wrote:
> On Tue, Oct 13, 2020 at 11:47:10AM -0500, Segher Boessenkool wrote:
> > On Tue, Oct 13, 2020 at 09:44:25AM +0200, Jakub Jelinek wrote:
> > > The following testcases are miscompiled (the first one since my
> >
+/* { dg-final { scan-assembler-times "vpmovzxdq\[
> \t\]+\\\(\[^\n\]*%xmm\[0-9\](?:\n|\[ \t\]+#)" 2 } } */
I don't know enough about the x86 backend to know if this is exactly
what you need in the testsuite. I do know a case of backslashitis when
I see one though -- you might want to use {} instead of "", and perhaps
\m and \M and \s etc. And to make sure things are on one line, don't do
all that nastiness with [^\n], just start the RE with (?n) :-)
Segher
Hi!
On Wed, Oct 14, 2020 at 01:43:45PM +0800, Hongtao Liu wrote:
> On Wed, Oct 14, 2020 at 4:01 AM Segher Boessenkool
> wrote:
> > On Tue, Oct 13, 2020 at 04:40:53PM +0800, Hongtao Liu wrote:
> > > For rtx like
> > > (vec_select:V2
On Wed, Oct 14, 2020 at 07:55:55PM +0200, Richard Biener wrote:
> On October 14, 2020 7:35:32 PM GMT+02:00, Segher Boessenkool
> wrote:
> >On Wed, Oct 14, 2020 at 01:43:45PM +0800, Hongtao Liu wrote:
> >> On Wed, Oct 14, 2020 at 4:01 AM Segher Boessenkool
> >> wrot
Hi!
On Thu, Oct 08, 2020 at 09:27:53AM +1030, Alan Modra wrote:
> This lays out the ground rules for following patches.
>
> * config/rs6000/rs6000.c (rs6000_rtx_costs): Expand comment.
This is okay for trunk. Thanks!
Segher
ive as shifts negative values would be UB,
> + to "A shift (B & (C - 1))". */
Maybe this can be phrased better? Not that I have any proposed text :-/
The patch looks good to me, fwiw.
Segher
gt;
> You will need a new enough GLIBC in order to do this configuration.
What happens if you glibc is older, and you try?
Segher
machine_mode arg_mode = TYPE_MODE (arg);
> + if (arg_mode == TFmode || arg_mode == TCmode)
> + {
> + uses_ieee128_p = true;
> + break;
> + }
I don't see why TFmode would mean it is IEEE? TFmode can be IBM128 as
well?
Segher
On Mon, Oct 19, 2020 at 03:12:13PM -0400, Michael Meissner wrote:
> On Fri, Oct 16, 2020 at 02:14:04PM -0500, Segher Boessenkool wrote:
> > On Thu, Sep 24, 2020 at 04:20:36PM -0400, Michael Meissner wrote:
> > > You will need a new enough GLIBC in order to do this configurat
asn't costed properly before,
but after your patch, a single instruction is replaced by three.
Could you look into this?
Segher
to GNU/Linux and this toolchain is
> + builtin on top of the corresponding header files. */
"built on top"?
> +/
> + * Common definitions first *
> + /
We don't use such decorated comments in GCC. But it is your header file
of course :-)
I don't see anything wrong with the actual code itself, fwiw :-)
Segher
On Thu, Oct 15, 2020 at 04:14:39PM +0800, Hongtao Liu wrote:
> On Thu, Oct 15, 2020 at 1:37 AM Segher Boessenkool
> wrote:
> > > + gcc_assert (can_div_trunc_p (SUBREG_BYTE (trueop0),
> > > +GET_MODE_SIZE (GET
t; + {
> + success = false;
> + break;
> + }
> + }
> + if (success)
If you have a huge piece of code like this, factor it? Esp. if you now
need to have all kinds of booleans where you really just want to do
early returns.
Segher
the previous version was better. We shouldn't assume that
> further simplification rules will fail just because the conditions
> for this rule haven't been met.
Yes. My suggestion was to factor this big piece of code to a separate
function, and do an early return from *that*.
The patch is okay for trunk without that, with the clumsy booleans.
Thanks Hongtao!
Segher
t; attacker correctly.
> > Right?
>
> Correct, but "very hard to be used" depends on how determined the attacker is.
Not only that, but the attacker only needs to get it right once, not for
every function (and not even for every program for that matter).
Segher
change?
No, please do, in a week or so, it is a pretty serious problem that we
could just asa well run into some other way, as far as I can see?
Segher
> gcc/
> PR target/97360
> * config/rs6000/rs6000-call.c (rs6000_init_builtins): Remove call to
> bui
On Wed, Oct 21, 2020 at 01:27:42PM +1030, Alan Modra wrote:
> On Tue, Oct 20, 2020 at 01:55:56PM -0500, Segher Boessenkool wrote:
> > On Thu, Oct 08, 2020 at 09:27:54AM +1030, Alan Modra wrote:
> > > The existing "case AND" in this fu
sign extend */
> vec_xl_zext() /* vector load zero extend */
> vec_xst_trunc() /* vector store truncate */.
I think this is fine now. Thanks! Okay for trunk.
Segher
On Thu, Oct 22, 2020 at 08:41:50AM +1030, Alan Modra wrote:
> On Wed, Oct 21, 2020 at 03:29:11PM -0500, Segher Boessenkool wrote:
> > Anyway:
> >
> > + || (outer_code == AND
> > + && rs6000_is_valid_2insn_and (x, mode)))
now you know
why :-)
Segher
In this case, it should be clear what file the
> error statement is in. What is your take in general about breaking or
> not breaking the body of an error print statement across lines?
Everyone agrees on that (I hope :-) )
The patch is okay for trunk. Thanks!
Segher
I'll get to it soon.
Segher
and rewrites this as:
>
> (mult:DI (sign_extend:DI (reg:SI r)) (const_int 2^n))
>
> instead of using a sign_extract.
That is only correct if SUBREG_PROMOTED_VAR_P is true and
SUBREG_PROMOTED_UNSIGNED_P is false for r. Is that guaranteed to be
true here (and how then?)
Segher
u can just call this dump_bb directly? And as a bonus you can dump it
to the dump file instead of to stderr ;-)
Segher
On Wed, Aug 19, 2020 at 04:03:31PM -0300, Tulio Magno Quites Machado Filho via
Gcc-patches wrote:
> Replace them with a whitespace in order to avoid artifacts in the HTML
> document.
Pushed to trunk now. Thanks!
Segher
ater cpus). But all is fine
for now it seems :-)
Segher
> in an AND, and offset_address_p of that time excluded altivec modes.)
>
> Regstrapped powerpc64le-linux power8 and power10, with tests on
> powerpc64-linux -m64/-m32 still running. OK assuming they pass?
I would be much happier if this was performance tested. But, it is okay
for trunk. Thanks!
Segher
won't work like this.
Easiest is to make an has_arch_pwr10 (in target-supports.exp), and use
that in the scan statements?
(As always, make sure this generates expected code :-) )
> --- a/gcc/testsuite/gcc.target/powerpc/pr86731-fwrapv-longlong.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr86731-fwrapv-longlong.c
> @@ -30,5 +30,5 @@ vector signed long long splats4(void)
>
> /* { dg-final { scan-assembler-times {\mvspltis[bhw]\M} 0 } } */
> /* { dg-final { scan-assembler-times {\mvsl[bhwd]\M} 0 } } */
> -/* { dg-final { scan-assembler-times {\mlvx\M|\mlxv\M|\mlxvd2x\M} 2 } } */
> +/* { dg-final { scan-assembler-times {\mlvx\M|\mlxv\M|\mlxvd2x\M|\mplxv\M} 2
> } } */
\mp?lxv\M
Segher
2401 - 2500 of 6091 matches
Mail list logo
