amp; 1" looks
> weird/inconsistent.
In most ports "&& 1" is all over the place and well-known already. Sure
we could change to "" meaning always, but that is not what it currently
means!
If we could just start all over we could do it perfectly (but see
second-system syndrome, heh). But we cannot. IMO we should especially
avoid everything that uses new semantics for old syntax.
Segher
On Thu, Jun 03, 2021 at 11:11:53AM -0600, Jeff Law wrote:
> On 6/3/2021 2:00 AM, Segher Boessenkool 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
> >tiny litt
On Thu, Jun 03, 2021 at 01:32:54PM -0600, Jeff Law wrote:
> On 6/2/2021 4:43 PM, Segher Boessenkool wrote:
> >We have has const0_rtx etc. since forever, this patch just increases the
> >range (to those values that have had guaranteed unique RTXes since
> >decades as well).
out
> the word instead.
This is a message for GCC developers, and it is not translated.
Segher
P10_BUILTIN_VCMPGTUT,
> > P10_BUILTIN_VCMPGTST, P10_BUILTIN_CMPLE_1TI,
> > P10_BUILTIN_CMPLE_U1TI]: New case statements.
>
> No signs of P10_BUILTIN_CMPNET below. possibly P10V_BUILTIN_CMPNET?
> S
> ame through at least P10_BUILTIN_CMPLE_U1TI.
It is P10V_BUILTIN_CMPNET (note the V).
Segher
ap upper/lower 64-bit values in a 128-bit vector
> +(define_insn "xxswapd_v1ti"
> + [(set (match_operand:V1TI 0 "vsx_register_operand" "=v")
> + (subreg:V1TI
> + (vec_select:V2DI
> + (subreg:V2DI
> +(match_operand:V1TI 1 "vsx_register_operand" "v") 0 )
> + (parallel [(const_int 1)(const_int 0)]))
> + 0))]
There are spaces instead of tabs on most of these lines.
Okay for trunk with the trivialities fixed. Also okay for GCC 11 once
it has been tested on all CPUs and OSes (all we care about that it :-) )
Thanks!
Segher
; * config/rs6000/dfp.md (floattitd2, fixtdti2): New define_insns.
> * config/rs6000/rs6000-call.c (P10V_BUILTIN_VCMPNET_P,
> P10V_BUILTIN_VCMPAET_P): New overloaded definitions.
That last line is just spurious?
Okay for trunk. Thanks!
Segher
dated.
Okay for trunk. Thanks!
Segher
mes, or
if it is just to make it clearer, or maybe something else? Some words
here would have helped :-)
Okay for trunk. Thanks!
Segher
define_insn you have, you can write just
{
if (BYTES_BIG_ENDIAN)
{
...
DONE;
}
}
This is the normal way of writing it. When a define_expand does not
call DONE or FAIL, the pattern is inserted in the insn stream.
Okay for trunk with the indents fixed, and maybe the expand thing. Also
okay for GCC 11 if it survived testing on all targets and OSes. That
goes for all patches in this series btw. Thanks!
Segher
power9-vector to
> add the necessary support.
You should simply not run this test on too new systems. You can use
dg-skip-if or similar.
> 3) Test code targetting at least power8 but go to power9 at the maximum.
But why? We will keep testing all interesting CPU / OS combos as long
as they are interesting.
Segher
eah, don't. Add a dg-skip-if if that is what you want. That
-mpower9-vector shouldn't be there either.
Segher
rst*, and then not have an "else". *That* is simpler.
And just write !(...) around the condition, don't try to manually invert
it please. You want both correct code and readable code, not neither of
these, they are not extremes you need to balance, each helps the other!
Segher
Is this okay for trunk?
Segher
2021-06-07 Segher Boessenkool
* gensupport.c (process_rtx) [DEFINE_INSN_AND_SPLIT]: Always include
the insn condition in the split condition.
---
gcc/gensupport.c | 25 -
1 file changed, 16 insertions(+), 9 deletion
uot;gpc_reg_operand")))]
> + "TARGET_POWER10 && TARGET_FLOAT128_HW && FLOAT128_IEEE_P (mode)"
> +{
> + if (rs6000_emit_cmove (operands[0], operands[1], operands[2], operands[3]))
> +DONE;
> + else
> +FAIL;
> +})
Why is this a special pattern anyway? Why can you not do
d = cond ? x : y;
with cond any comparison, not even including any floating point
possibly?
Segher
On Mon, Jun 07, 2021 at 03:41:29PM -0500, Pat Haugen wrote:
> Update Power10 scheduling description for new fused instruction types.
Okay for trunk. Thanks!
Segher
t will need any significant fixing, maybe none
at all will be needed across all targets. And no changes will be needed
anywhere immediately. We could make leading "&&" deprecated, and the
same for split condition "1" (which was "&& 1"). This is easy to change
automatically as well.
Segher
On Tue, Jun 08, 2021 at 09:05:57AM +0200, Richard Biener wrote:
> On Tue, Jun 8, 2021 at 12:05 AM Segher Boessenkool
> wrote:
> >
> > In theory we could have a split condition not inclusive of the insn
> > condition in the past. That never was a good idea, the code do
On Tue, Jun 08, 2021 at 09:08:56AM +0200, Richard Biener wrote:
> On Tue, Jun 8, 2021 at 4:10 AM Kewen.Lin via Gcc-patches
> wrote:
> > on 2021/6/8 上午7:50, Segher Boessenkool wrote:
> > > On Fri, Jun 04, 2021 at 10:57:51AM +0800, Kewen.Lin via Gcc-patches wrote:
> >
> they won't regress again.
Just some target macro might be better / easier? Just gensupport.c will
need to use it.
Will we still allow empty split conditions? And automatically make that
do the equivalent of "&& 1"?
Segher
On Tue, Jun 08, 2021 at 04:50:56PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Tue, Jun 08, 2021 at 02:48:11PM +0200, Richard Biener wrote:
> >> > So yeah, patch withdrawn. This on one hand is proof we do want to make
> >> > such a chang
red*
alternative with cost 12, while the other alternative has cost 8. Why
is that? That looks like a bug.
(set_attr "length" "12,8")
> >> By hacking the vsx_le_perm_store_v1ti INSN_COST from 12 to 8,
> >
> > It should be the same cost as the other store!
>
> vsx_le_permute_v1ti's cost is defined to 4 in vsx.md:
Yes. Why is alternative 0 of *vsx_le_perm_store_ said to have a
length of 3 insns?
Segher
(which
implicitly sets this). So just remove that dg-require please.
> +/* { dg-final { scan-assembler-not "xxpermdi" } } */
> +/* { dg-final { scan-assembler-not "stxvd2x" } } */
> +/* { dg-final { scan-assembler-not "lxvd2x" } } */
It is a good habit to use \m and \M in the scans where you can (those
are the same as \< and \> are in some other regexp dialects). They
aren't absolutely necessary here of course.
Okay for trunk with those fixes. Thanks!
Segher
s "vmrgow" 8 } } */
> -/* { dg-final { scan-assembler-times "vmrglb" 5 { target le } } } */
> +/* { dg-final { scan-assembler-times "vmrglb" 4 { target le } } } */
> /* { dg-final { scan-assembler-times "vmrglb" 6 { target be } } } */
> /* { dg-final { scan-assembler-times "vmrgew" 8 } } */
> /* { dg-final { scan-assembler-times "vsplth" 8 } } */
Are those changes correct? It looks like a vmrglb became a vmrghb, and
that 4 each of xxmrghw and xxmrglw disappeared? Both seem wrong?
Segher
# 35 [c=4 l=4] xxswapd_v4sf
>
> Note that v0 and v12 is swapped in lxvd2x, these new 3 instructions
> produces same result than before.
And there was one xxmrglw in this snippet before, and now there still
is only one.
But, the testcase uses -dp, I see. Please use \m and \M in the scans,
it helps :-) (And convert more than just the few that hit errors ;-) )
(You may want to do that as a separate patch before this one, to make
counting easier (also for me ;-) ),
(I'll review the new patch later today).
Segher
ctually make sense? It seems too be
two themes: long long being two regs / two insns on 32-bit, and the
you get cmpld etc. only on 64-bit?
Okay for trunk if this is actually the expected output. Thanks!
Segher
On Wed, Jun 09, 2021 at 11:20:20AM +0800, Xionghu Luo wrote:
> On 2021/6/9 04:11, Segher Boessenkool wrote:
> > On Fri, Jun 04, 2021 at 09:40:58AM +0800, Xionghu Luo wrote:
> >>>> rejecting combination of insns 6 and 7
> >>>> original costs 4 + 4 = 8
> &g
On Wed, Jun 09, 2021 at 11:06:31AM +0800, Xionghu Luo wrote:
> On 2021/6/9 05:07, Segher Boessenkool wrote:
> >> -/* { dg-final { scan-assembler "lxvd2x 34" } } */
> >> -/* { dg-final { scan-assembler "stxvd2x 34" } } */
> >> +/* { dg-final {
Mark registers that are being referenced in this value. */
>if (value)
> - update_table_tick (value);
> +{
> + gcc_assert (insn);
> + update_table_tick (value, DF_INSN_LUID (insn));
> +}
Don't add that assert please. If you really want one it should come
right at the start of the function, not 60 lines later :-)
Looks good if I understood this correctly :-)
Segher
build_pointer_type (vector_quad_type_node);
> else if (gimple_func && mode == OOmode
Pleae write the
&& mode == OOmode
on a new line as well then?
> + int index = WORDS_BIG_ENDIAN ? i: nvecs - 1 - i;
Space before colon.
Okay for trunk and 11 with at least that space fixed. Thanks!
Segher
-final { scan-assembler-not "mfvsrwz" } } */
> +/* { dg-final { scan-assembler-not "mtvsrd" } } */
> +/* { dg-final { scan-assembler-not "mtvsrwa" } } */
> +/* { dg-final { scan-assembler-not "mtvsrwz" } } */
Here as well, or you could just do
/* { dg-final { scan-assembler-not "\mm[tf]vsr" } } */
in this case, since no VSR<->GPR moves should happen at all.
Segher
Hi!
On Thu, Jun 10, 2021 at 05:32:23PM +0800, Kewen.Lin wrote:
> +/* { dg-do compile { target lp64 } } */
One final thing: what requires lp64 here? Could you try without please?
Okay for trunk with that considered. Thanks!
Segher
The *TItype_ppc definitions are guarded by _ARCH_PPC64, so all
declarations using it should do so as well.
This fixes it. Committed to trunk.
Segher
2021-06-10 Segher Boessenkool
libgcc/
* config/rs6000/quad-float128.h: Guard all uses of [U]TItype_ppc by
_ARCH_PPC64
On Thu, Jun 10, 2021 at 10:43:05AM -0500, Peter Bergner wrote:
> On 6/9/21 4:38 PM, Segher Boessenkool wrote:
> > I think this reads simpler as
> > /* The ASSEMBLE builtin source operands are reversed in little-endian
> > mode, so reorder them. *
the same maximum displacement as D operands, we just force that their
> bottom 2-bits/4-bits must be zero, so we don't need to include them in the
> insn encoding. I believe this is all just handled in our legitimate address
> routines, but maybe Segher and/or Mike can correct me if I&
egtest is passes, ok for trunk and backport to 11?
Yes. Thank you!
Segher
On Thu, Jun 10, 2021 at 03:11:08PM +0800, Xionghu Luo wrote:
> On 2021/6/10 00:24, Segher Boessenkool wrote:
> >>"!BYTES_BIG_ENDIAN && TARGET_VSX && reload_completed &&
> >> !TARGET_P9_VECTOR
> >> && !altivec_ind
ltin-vec_rlnm-runnable.c
(dg-require-effective-target): Change target to p9vector_hw.
Okay for trunk like that. Thanks!
Segher
On Fri, Jun 11, 2021 at 08:45:53PM +0800, Kewen.Lin wrote:
> on 2021/6/10 下午6:58, Segher Boessenkool wrote:
> > On Thu, Jun 10, 2021 at 05:32:23PM +0800, Kewen.Lin wrote:
> >> +/* { dg-do compile { target lp64 } } */
> >
> > One final thing: what requires lp64 here?
letions(-)
> create mode 100644 gcc/testsuite/gcc.target/powerpc/unwind-backchain.c
So what is new or different in v3 compared to v2?
Segher
On Wed, Oct 06, 2021 at 10:09:31AM -0300, Raphael M Zinsly wrote:
> On 05/10/2021 19:03, Segher Boessenkool wrote:
> >So what is new or different in v3 compared to v2?
>
> gcc/testsuite/gcc.target/powerpc/unwind-backchain.c:
> - Added a comment explaining why test only
ion the version history after a --- (see --notes for git-format-patch
for example).
> Tested ppc64le (POWER9) and ppc64/32 (POWER7).
Please write the full triples -- well at least enough that they are
usable, like, powerpc64-linux. I'll assume you tested on Linux :-)
Segher
r than mffs. So allowing this builtin to be used everywhere makes
it easier to use, with no real downsides.
Segher
after
it was added, because no one who tests often does that on so old
hardware :-)
So, okay for trunk (and backports after some burn-in) with that vsx_ok
fixed. That asm needs fixing, but you can do that later.
Thanks!
Segher
On Thu, Oct 07, 2021 at 08:04:23PM -0500, Paul A. Clarke wrote:
> On Thu, Oct 07, 2021 at 06:39:06PM -0500, Segher Boessenkool wrote:
> > > + __asm__ __volatile__ ("mffsce %0" : "=f" (__fpscr_save.__fr));
> >
> > The __volatile__ does likely not do
On Fri, Oct 08, 2021 at 02:27:28PM -0500, Paul A. Clarke wrote:
> On Fri, Oct 08, 2021 at 12:39:15PM -0500, Segher Boessenkool wrote:
> > This is not a basic asm (it contains a ":"; that is not just an easy way
> > to see it, it is the *definition* of basic vs. extende
on by default, which generates unexpected float
> + conversion for vector construction, so simply disable it. */
It is good to see these comments. I love puzzles, but not in the
testsuite! :-)
Okay for trunk. Thanks!
Segher
return false;
> +?? /* Fall through to MIN_EXPR.?? */
> +?? gcc_fallthrough ();
> case P8V_BUILTIN_VMINSD:
> case P8V_BUILTIN_VMINUD:
> case ALTIVEC_BUILTIN_VMINSB:
Yeah I would rather not review this like this :-)
Segher
On Mon, Oct 11, 2021 at 10:55:36AM -0500, Segher Boessenkool wrote:
> On Thu, Aug 26, 2021 at 09:19:30AM +0800, HAO CHEN GUI wrote:
> > gcc/
> > ?? * config/rs6000/rs6000-call.c (rs6000_gimple_fold_builtin):
> > ?? Modify the VSX_BUILTIN_XVMINDP, A
On Mon, Oct 11, 2021 at 08:46:17AM -0500, Paul A. Clarke wrote:
> On Fri, Oct 08, 2021 at 05:31:11PM -0500, Segher Boessenkool wrote:
> > "asm volatile" means there is a side effect in the asm. This means that
> > it has to be executed on the real machine the same as on
On Mon, Oct 11, 2021 at 10:23:03AM -0600, Martin Sebor wrote:
> On 10/11/21 9:30 AM, Segher Boessenkool wrote:
> >On Mon, Oct 11, 2021 at 10:47:00AM +0800, Kewen.Lin wrote:
> >>- For generic test cases, it follows the existing suggested
> >>practice with necessary target
target/powerpc/sse4_1-pminsd.c: Same.
> * gcc.target/powerpc/sse4_1-pminud.c: Same.
> * gcc.target/powerpc/sse4_1-pminuw.c: Same.
Okay for trunk. Thanks!
Segher
for trunk either way. Thanks!
Segher
e :-)
Having up to three unpacks in a row seems suboptimal. But it certainly
is aesthetically pleasing :-)
> +/* { dg-do run } */
> +/* { dg-require-effective-target powerpc_vsx_ok } */
> +/* { dg-options "-O2 -mvsx" } */
Same as before here too (needs vsx_hw).
Okay for trunk with that fixed. Thanks!
Segher
Hi!
On Mon, Oct 11, 2021 at 12:31:07PM -0500, Paul A. Clarke wrote:
> On Mon, Oct 11, 2021 at 11:28:39AM -0500, Segher Boessenkool wrote:
> > > Very similar methods are used in glibc today. Are those broken?
> >
> > Maybe.
>
> Ouch.
So show the code?
> >
t; * gcc.target/powerpc/sse4_1-pmulld.c: Same.
> * gcc.target/powerpc/sse4_2-pcmpgtq.c: Same.
> * gcc.target/powerpc/sse4_2-check.h: Copy from gcc.target/i386,
> tweak to suit.
Okay for trunk (with the vsx_hw thing). Thanks!
Segher
; - _mm_sign_pi8: depends on _mm_sign_epi8.
> - _mm_sign_pi16: depends on _mm_sign_epi16.
> - _mm_sign_pi32: depends on _mm_sign_epi32.
And more.
> gcc
> PR target/101893
This is a different bug (the vgbdd one)?
All looks good, but we need such failing tests :-)
Segher
On Thu, Oct 07, 2021 at 07:29:26PM -0500, Paul A. Clarke wrote:
> On Thu, Oct 07, 2021 at 05:25:54PM -0500, Segher Boessenkool wrote:
> > On Mon, Aug 23, 2021 at 02:03:04PM -0500, Paul A. Clarke wrote:
> > > v3: Add "nmmintrin.h". _mm_cmpgt_epi64 is part of SSE4.2
&g
do not expect to be able to fix the
bug causing this any time soon. There shouldn't be one here, not yet
anyway.
Other than that: yes, and one you have such a selector, just dg-require
it (or its inverse) for this test, don't xfail the test (if this is
expected and correct behaviour).
Segher
On Tue, Oct 12, 2021 at 11:15:51AM -0600, Martin Sebor wrote:
> On 10/12/21 10:18 AM, Segher Boessenkool wrote:
> >On Tue, Oct 12, 2021 at 09:49:19AM -0600, Martin Sebor wrote:
> >>Coming back to the xfail conditionals, do you think you'll
> >>be able to put togeth
On Mon, Oct 11, 2021 at 02:07:49PM -0600, Martin Sebor wrote:
> On 10/11/21 11:43 AM, Segher Boessenkool wrote:
> >I also am okay with this. If it was decided x86 does not have to deal
> >with these (generic!) problems, then why should we do other people's
> >work?
>
" } */
If you need vsx_hw (or vsx_ok), you need -mvsx in the options as well.
(Always, so in both testcases here).
Segher
has to stay in order with all FP control writes and FP
status reads".
Maybe now you see why I like external functions for this :-)
> This
> is not used in the code above because I believe it first appears in
> GCC 9.1 or so, and glibc still supports GCC 6.2 (and it doesn't define
> a return value, which would be handy in this case). Does the
> implementation of that builtin meet the requirements needed here,
> to prevent reordering of FP computation across instantiations of the
> builtin? If not, is there a model on which to base an implementation
> of __builtin_mffsce (or some preferred name)?
It depends on what you are actually ordering, unfortunately.
Segher
.
When used with floating point, if both operands are zeros, or if either
operand is @code{NaN}, then it is unspecified which of the two operands
is returned as the result.
"""
(not exactly meaningless, okay, but not usable for almost anything).
> But that can then still happen with -ffast-math so I wonder what's the point.
That :-)
Segher
compile { target { powerpc*-*-* } } } */
Leave out the target clause? Testcases in gcc.target/powerpc/ are not
run when this is not satisfied anyway, testing it twice is just more
noise.
Segher
On Wed, Oct 13, 2021 at 12:04:39PM -0500, Paul A. Clarke wrote:
> On Mon, Oct 11, 2021 at 07:11:13PM -0500, Segher Boessenkool wrote:
> > > - _mm_mul_epu32: vec_mule(v4su) uses vmuleuw.
> >
> > Did this fail on p7? If not, add a test that *does*?
>
> Do you me
the alternative 'Z' of "lfiwzx" when reload is
> needed.
"Disparage", no "s". Changelog entries are written in the imperative.
Segher
sd*
Only powerpc64-unknown-freebsd was checked for.
Signed-off-by: Piotr Kubaj
gcc/
* configure.ac: Treat powerpc64*-*-freebsd* the same as
powerpc64-*-freebsd*.
* configure: Regenerate.
===
Segher
alyze 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)
Your patches cannot apply. Please send them non-wordwrapped.
This isn't the endpoint of the changes here I hope? The macro games
make everything less readable (so, harder to change) and more fragile.
Segher
ou can help it, it
is meaningless in email.
Use git send-email, it makes everything work :-)
Segher
s="${extra_headers} pmmintrin.h tmmintrin.h smmintrin.h"
> > + extra_headers="${extra_headers} nmmintrin.h"
> > extra_headers="${extra_headers} ppu_intrinsics.h spu2vmx.h vec_types.h
> > si2vmx.h"
> > extra_headers="${extra_headers} amo.h"
> > case x$with_cpu in
>
> In my opinion, you can commit this one as obvious.
Or as trivial. Or as obvious and trivial :-)
Segher
es).
> gcc
> PR target/101893
> PR target/102719
> * config/rs6000/emmintrin.h: Guard POWER8 intrinsics.
> * config/rs6000/pmmintrin.h: Same.
> * config/rs6000/smmintrin.h: Same.
> * config/rs6000/tmmintrin.h: Same.
Okay for trunk. Thanks!
Segher
he xvmindp
builtin handle less than it does currently? And, what about vminfp?
Did tht do the wrong thing before?
There are no tests for any of that apparently. Hrm.
Segher
ate->init_sections ();
> +
> + return target_state;
> +}
>
> If you'd have made init_sections virtual the flow would be more
> natural and we could separate section init from casm construction
> (and rs6000 would override init_sections but call the base function
> from the override).
Yeah.
Segher
On Mon, Oct 25, 2021 at 12:46:30PM +0200, Richard Biener wrote:
> On Thu, Oct 21, 2021 at 5:42 PM Segher Boessenkool
> wrote:
> > It's disgusting, and fragile. The define is slightly better than having
> > to write it out every time. But can this not be done properly?
&g
ind information, when
> known.
> + The section is set either by the target's init_sections hook or by the
> + first call to switch_to_eh_frame_section. */
> +section *eh_frame;
> +
> +/* RS6000 sections. */
Nothing here? Just remove the comment header?
The idea looks fine to me.
Segher
cpu=power8 instead? (And -mdejagnu-cpu=power8 in
testcases).
(The changelog should say you added the -D btw).
If you run you need *_hw. If you only compile, like here, you want to
use *_ok instead.
Okay for trunk with those things tuned up. Thanks!
Segher
This fixes bootstrap for the current problems building libffi.
I'll work on getting this into upstream as well. If the maintainers
want it done differently, at least we have bootstrap working again
until then.
Tested on powerpc64-linux {-m32,-m64}.
Segher
2021-10-25 Segher Boesse
On Sun, Oct 17, 2021 at 02:28:48AM +0200, Piotr Kubaj wrote:
> On 21-10-16 18:57:39, Segher Boessenkool wrote:
> > On Sat, Oct 16, 2021 at 04:09:05AM +0200, Piotr Kubaj wrote:
> > > Only powerpc64-unknown-freebsd was checked for.
> > >
> > > Signed-off-by: Piot
Hi!
On Wed, Oct 27, 2021 at 11:44:59AM -0700, H.J. Lu wrote:
> On Mon, Oct 25, 2021 at 4:39 PM Segher Boessenkool
> wrote:
> > This fixes bootstrap for the current problems building libffi.
> >
> > I'll work on getting this into upstream as well. If the maintainers
On Fri, Jul 02, 2021 at 01:32:45PM -0500, Peter Bergner wrote:
> On 7/1/21 2:48 PM, Peter Bergner wrote:
> > On 7/1/21 1:01 PM, Segher Boessenkool wrote:
> >> The patch is okay for trunk.
> >
> > Below is the updated patch which is bootstrapping now. I'll commi
x27;t you do that here, wouldn't that work much
better? There are many more insns that you may want to hide. The
traditional solution is to use unspecs, which very directly hides all
details.
Segher
. That said, how about the following
> >> change to resolve the issue you have? I'll kick off a bootstrap and
> >> regtest for this change.
> >
> >
> > Thanks, yes, that works for me!
>
> Great, thanks!
>
>
> Segher, the patch was clean on
Hi!
On Wed, Jul 07, 2021 at 10:15:08AM +0200, Richard Biener wrote:
> On Wed, Jul 7, 2021 at 4:40 AM Hongtao Liu via Gcc-patches
> wrote:
> > On Tue, Jul 6, 2021 at 9:37 AM Hongtao Liu wrote:
> > > On Tue, Jul 6, 2021 at 7:31 AM Segher Boessenkool
> > > wrote:
>
And maybe some clobbers?
Segher
Hi!
On Wed, Jul 07, 2021 at 05:02:42PM +0800, Kewen.Lin wrote:
> This patch is to add test cases to check if vectorizer
> can exploit vector multiply instrutions on Power, some
> of them are supported since Power8, the other are newly
> introduced by Power10.
Okay for trunk. Thank you!
Segher
On Wed, Jul 07, 2021 at 05:03:07PM +0800, Kewen.Lin wrote:
> This patch is to add one test case to check if vectorizer
> can exploit vector division instrutions newly introduced
> by Power10.
Okay, great, thanks!
Segher
(umod3): ... this.
("Rename", not "Renamed")
(It reads better if you put the "Adjust" entry after the rest, btw)
So I suppose the new testcase FAILs without these changes?
Okay for trunk. Thanks!
Segher
ot;)
(every eight leading spaces should be tabs -- multiple times here)
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/p10-vdivq-vmodq.c
> @@ -0,0 +1,27 @@
> +/* { dg-require-effective-target lp64 } */
int128, instead. There is nothing here that needs lp64. If there was,
that should be commented here, too.
Okay for trunk with those fixes. Also okay for all backports. Please
make sure it tested on all usual platforms before backporting. Thanks!
Segher
On Wed, Jul 07, 2021 at 11:23:48PM +0800, Hongtao Liu wrote:
> On Wed, Jul 7, 2021 at 10:54 PM Segher Boessenkool
> wrote:
[ snip some old stuff ]
> > Yeah. This stuff needs a rethink.
> >
> > What is wrong with just using an unspec and clobbers?
> >
> It&
On Wed, Jul 07, 2021 at 11:32:59PM +0800, Hongtao Liu wrote:
> On Wed, Jul 7, 2021 at 10:54 PM Segher Boessenkool
> wrote:
> > So, a "FAKE_CALL" is very much a *real* call, on the RTL level, which is
> > where we are here. But you want it to be treated differently be
dex_next)
> + : XVECEXP (src, 0, index);
Please get rid of index_next, if you still have to do different code for
LE here -- it doesn't make the code any clearer (in fact I cannot follow
it at all anymore :-( )
So this converts pairs of lxv to an lxvp in only a very limited case,
right? Can we instead do it more generically? And what about stxvp?
Segher
On Thu, Jul 08, 2021 at 08:26:45PM -0500, Peter Bergner wrote:
> On 7/8/21 6:28 PM, Segher Boessenkool wrote:
> >> int index = WORDS_BIG_ENDIAN ? i : nvecs - 1 - i;
> >> -rtx dst_i = gen_rtx_REG (reg_mode, reg + index);
> >> -emit_insn (gen_r
some targets that do not have machine insns for this
(but want to generate different code for this anyway) can do pretty much
anything.
Maybe using just Pmode here is good enough though?
Segher
On Mon, Jul 12, 2021 at 06:19:28AM +0200, Martin Liška wrote:
> PING^1
I did not notice you attached a new patch. It works a lot better if
every patch series is a new thread.
Segher
On Mon, Jun 28, 2021 at 02:19:03PM +0200, Martin Liška wrote:
> On 6/24/21 12:46 AM, Segher Boessenkool wrote:
> >>As mentioned in the "Fallout: save/restore target options in
> >>handle_optimize_attribute"
> >>thread, we need to support target option res
er-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|\mplvx\M} 2 } } */
>
> Oopsie. I think you mean "plxv" for this one.
So why did testing not catch it?
Thanks for the review Bill! :-)
Segher
ionale
whatsoever for any of these changes, and the approach is different for
every case as well. This means every case needs separate checking
whether it is correct, which is more work than doing the changes in the
first place.
Mechanically just changing things so the test cases pass is **wrong**.
Segher
etc.) We really should impprove that :-(
If it had used powerpc64 here, there would not have been this confusion.
The problem in fixing this of course is the historical uses of this
test. Bah.
Segher
ecommend approval with line lengths fixed.
It is okay for trunk with whatever changes you want to do. Thanks!
Segher
1201 - 1300 of 6091 matches
Mail list logo
