On Tue, 2021-05-18 at 16:49 -0400, Michael Meissner wrote:
> [PATCH] Fix vec-splati-runnable.c test.
>
hi,
> I noticed that the vec-splati-runnable.c did not have an abort after one
> of the tests. If the test was run with optimization, the optimizer could
> delete some of the tests and throw
On Tue, 2021-05-18 at 16:57 -0400, Michael Meissner wrote:
> [PATCH 1/2] Deal with prefixed loads/stores in tests, PR testsuite/100166
>
Hi,
> This patch updates the various tests in the testsuite to treat plxv
> and pstxv as being vector loads/stores. This shows up if you run the
> testsuite w
On Tue, 2021-05-18 at 16:59 -0400, Michael Meissner wrote:
> [PATCH 2/2] Fix tests when running on power10, PR testsuite/100166
>
Hi,
> This patch updates the various tests in the testsuite to adjust the test
> if power10 code generation is used.
>
> Some tests would not generate the expected i
On Fri, 2021-06-04 at 11:10 -0400, Michael Meissner wrote:
Hi,
> Generate 128-bit divide/modulus.
>
> This patch adds support for the VDIVSQ, VDIVUQ, VMODSQ, and VMODUQ
> instructions to do 128-bit arithmetic.
vdivsq,vdivuq,vmodsq,vmoduq should be lowercase ?
>
> I have tested this on 3 co
On Wed, 2021-06-30 at 09:44 +0800, Xionghu Luo via Gcc-patches wrote:
> Gentle ping ^2, thanks.
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568143.html
>
>
> On 2021/5/14 15:13, Xionghu Luo via Gcc-patches wrote:
> > Test SPEC2017 Ofast P8LE for this patch : 511.povray_r +1.14%,
> >
On Thu, 2021-06-17 at 10:18 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-06-07 Bill Schmidt
>
> gcc/
> * config/rs6000/rs6000-gen-builtins.c (consume_whitespace): New
> function.
> (advance_line): Likewise.
> (safe_inc_pos): Likewise.
> (match_identifier): Lik
On Fri, 2021-07-23 at 15:23 -0500, Pat Haugen via Gcc-patches wrote:
> Ping
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555760.html
>
> I've done a current bootstrap/regtest on powerpc64/powerpc64le with
> no regressions.
>
> -Pat
That patch was previously posted by Alan Modra.
Giv
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-06-17 Bill Schmidt
>
Hi,
> gcc/
> * config/rs6000/rs6000-call.c (rs6000_expand_new_builtin): New
> forward decl.
> (rs6000_invalid_new_builtin): New stub function.
> (rs6000_expand_builtin):
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-03-05 Bill Schmidt
>
Hi,
> gcc/
> * config/rs6000/rs6000-call.c (rs6000_invalid_new_builtin):
> Implement.
> (rs6000_expand_ldst_mask): Likewise.
> (rs6000_init_builtins): Initialize altivec_
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-03-05 Bill Schmidt
>
Hi,
> gcc/
> * config/rs6000/rs6000-call.c (new_cpu_expand_builtin):
> Implement.
ok
> ---
> gcc/config/rs6000/rs6000-call.c | 100
> 1 file cha
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-06-17 Bill Schmidt
>
Hi,
> gcc/
> * config/rs6000/rs6000-call.c (new_mma_expand_builtin):
> Implement.
Ok,
> ---
> gcc/config/rs6000/rs6000-call.c | 103
> 1 file cha
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-03-24 Bill Schmidt
>
> gcc/
> * config/rs6000/rs6000-call.c (new_htm_spr_num): New function.
> (new_htm_expand_builtin): Implement.
> (rs6000_expand_new_builtin): Handle 32-bit and endian cases.
> --
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-03-05 Bill Schmidt
>
Hi,
> gcc/
> * config/rs6000/rs6000-call.c (elemrev_icode): Implement.
> (ldv_expand_builtin): Likewise.
> (lxvrse_expand_builtin): Likewise.
> (lxvrze_expand_builtin):
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-04-01 Bill Schmidt
>
> gcc/
> * config/rs6000/rs6000-call.c (rs6000_debug_type): New function.
> (def_builtin): Change debug formatting for easier parsing and
> include more information.
> (rs6
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-06-10 Bill Schmidt
>
> gcc/
> * config/rs6000/altivec.h: Delete a number of #defines that are
> now superfluous; include rs6000-vecdefines.h; include some
> synonyms.
> ---
> gcc/config/rs6000/altiv
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-03-05 Bill Schmidt
>
> gcc/
> * config/rs6000/rs6000-gen-builtins.c (write_init_file):
> Initialize new_builtins_are_live to 1.
> ---
> gcc/config/rs6000/rs6000-gen-builtins.c | 2 +-
> 1 file changed, 1
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-03-05 Bill Schmidt
>
Hi,
Description could be a bit longer. :-) (Even just a duplicate of the
mail subject to fill the space would prob be fine.)
> gcc/
> * config/rs6000/rs6000-call.c (rs6000_new_builtin_
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-03-05 Bill Schmidt
>
Hi,
Could use a longer description.
> gcc/
> * config/rs6000/rs6000.c (rs6000_builtin_reciprocal): Use
> rs6000_builtin_decls_x when appropriate.
> (add_condition_to_bb):
On Wed, 2021-05-26 at 10:59 +0800, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
Hi,
> This is the updated version of patch to deal with the bwaves_r
> degradation due to vector construction fed by strided loads.
>
> As Richi's comments [1], this follows the similar idea to over
> price the vector
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
Hi,
> This is another patch that looks bigger than it really is. Because we
> have a new namespace for the builtins, allowing us to have both the old
> and new builtin infrastructure supported at once, we need versions of
>
On Sun, 2021-04-25 at 20:50 -0500, Bill Schmidt via Gcc-patches wrote:
> Add POWER10 support for hashst[p] and hashchk[p] operations. When
> the -mrop-protect option is selected, any function that loads the
> link
> register from memory before returning must have protection in the
> prologue and e
On Sun, 2021-04-25 at 20:50 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-03-25 Bill Schmidt
>
> gcc/
> * config/rs6000/rs6000.c (rs6000_option_override_internal):
> Disable shrink wrap when inserting ROP-protect instructions.
> * config/rs6000/rs6000.opt (mrop-protect): N
On Sun, 2021-04-25 at 20:50 -0500, Bill Schmidt via Gcc-patches wrote:
> Insert the hashst and hashchk instructions when -mrop-protect has been
> selected. The encrypted save slot for ROP mitigation is placed
> between the parameter save area and the alloca space (if any;
> otherwise the local var
On Sun, 2021-04-25 at 20:50 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-03-25 Bill Schmidt
>
> gcc/
> * config/rs6000/rs6000-c.c (rs6000_target_modify_macros): Define
> __ROP_PROTECT__ if -mrop-protect is selected.
ok
> ---
> gcc/config/rs6000/rs6000-c.c | 3 +++
> 1 file
On Sun, 2021-04-25 at 20:50 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-03-25 Bill Schmidt
>
> gcc/testsuite/
> * gcc.target/powerpc/rop-1.c: New.
> * gcc.target/powerpc/rop-2.c: New.
> * gcc.target/powerpc/rop-3.c: New.
> * gcc.target/powerpc/rop-4.c: New.
>
On Mon, 2021-04-26 at 13:04 -0500, acsaw...@linux.ibm.com wrote:
> From: Aaron Sawdey
>
> This adds new values for insn attr type for p10 fusion. The
> genfusion.pl
> script is modified to use them, and fusion.md regenerated to capture
> the new patterns. There are also some formatting only chang
On Mon, 2021-04-26 at 14:00 -0500, acsaw...@linux.ibm.com wrote:
> From: Aaron Sawdey
>
> This adds some test cases to make sure that the combine patterns for p10
> fusion are working.
>
> OK for trunk?
>
> gcc/testsuite/ChangeLog:
> * gcc.target/powerpc/fusion-p10-ldcmpi.c: New file.
>
On Mon, 2021-04-26 at 09:36 -0700, Carl Love wrote:
> Will, Segher:
>
> This patch adds support for converting to/from 128-bit integers and
> 128-bit decimal floating point formats using the new P10 instructions
> dcffixqq and dctfixqq. The new instructions are only used on P10 HW,
> otherwise th
On Mon, 2021-04-26 at 09:36 -0700, Carl Love wrote:
> Will, Segher:
>
> This patch adds the 128-bit integer support for divide, modulo, shift,
> compare of 128-bit integers instructions and builtin support.
Hi,
>
> The patch has been tested on
> powerpc64-linux instead (Power 8 BE)
> po
On Mon, 2021-04-26 at 09:36 -0700, Carl Love wrote:
> Will, Segher:
>
> The previous patch added the vector 128-bit integer shift instruction
> support for the V1TI type. This patch renames and moves the VSX_TI
> iterator from vsx.md to VEC_TI in vector.md. The uses of VEC_TI are
> also updated.
On Mon, 2021-04-26 at 09:36 -0700, Carl Love wrote:
> Will, Segher:
>
Hi,
> This patch adds support for converting to/from 128-bit integers and
> 128-bit decimal floating point formats.
You reference TI,TD in the subject, would be helpful to elaborate a bit in your
description.
>
> The p
On Mon, 2021-04-26 at 09:35 -0700, Carl Love wrote:
> Will, Segher:
>
> This patch fixes the order of the argument in the vec_rlmi and
> vec_rlnm builtins. The patch also adds a new test cases to verify
> the fix.
>
> The patch has been tested on
> powerpc64-linux instead (Power 8 BE)
>
On Fri, 2021-05-07 at 10:28 +0800, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> When I was investigating density_test heuristics, I noticed that
> the current rs6000_density_test could be used for single scalar
> iteration cost calculation, through the call trace:
> vect_compute_single_scalar_iter
On Fri, 2021-05-07 at 12:19 +0930, Alan Modra via Gcc-patches wrote:
> PowerPC64 ELFv2 dual entry point functions have a couple of problems
> with -fpatchable-function-entry. One is that the nops added after the
> global entry land in the global entry code which is constrained to be
> a power of t
On Fri, 2021-05-07 at 12:19 +0930, Alan Modra via Gcc-patches wrote:
> This reverts commit b680b9049737198d010e49cf434704c6a6ed2b3f now
> that the PowerPC64 ELFv1 regression is fixed properly.
>
Hi,
Ok. looks like that was initially handled by Jakub, on copy, good. :-)
Contents below appear to
On Fri, 2021-05-07 at 12:19 +0930, Alan Modra via Gcc-patches wrote:
> On PowerPC64 ELFv1 function symbols are defined on function
> descriptors in an .opd section rather than in the function code.
> .opd is not split up by the PowerPC64 backend for comdat groups or
> other situations where per-fun
On Thu, 2020-08-13 at 13:29 -0500, Segher Boessenkool wrote:
> On Thu, Aug 13, 2020 at 11:09:10AM -0700, Carl Love wrote:
> > The builtins
> >
> > vector signed int vec_signexti (vector signed char a)
> > vector signed long long vec_signextll (vector signed char a)
> > vector signed int vec_signex
On Tue, 2020-08-11 at 12:22 -0700, Carl Love wrote:
> Segher, Will:
>
> Patch 2, adds support for divide, modulo, shift, compare of 128-bit
> integers. The support adds the instruction and builtin support.
>
> Carl Love
>
>
> ---
On Thu, 2020-08-13 at 17:55 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Aug 13, 2020 at 05:11:11PM -0500, will schmidt wrote:
> > > > That is probably a level of detail that is not
> > > > really needed in the GCC code comment. Probably best to just
> > > > change
> > > > the comment to re
On Tue, 2020-08-11 at 12:22 -0700, Carl Love wrote:
> Segher, Will:
>
> Path 3 adds support for converting to/from 128-bit integers and 128-bit
> decimal floating point formats.
>
> Carl Love
>
Some cosmetic comments below. overall lgtm.
Thanks,
-Will
>
> ---
On Tue, 2020-08-11 at 12:23 -0700, Carl Love wrote:
> Segher, Will:
>
> Patch 4 adds 128-bit integer shift instruction support.
I suggest having a few more words here to better describe what this
patch is doing.
i.e.
This is adding the VEC_I128 iterator which contains the V1TI and TI
types, an
On Tue, 2020-08-11 at 12:23 -0700, Carl Love wrote:
> Segher, Will:
>
> Patch 5 adds the 128-bit integer to/from 128-floating point
> conversions. This patch has to invoke the routines to use the 128-bit
> hardware instructions if on Power 10 or use software routines if
> running on a pre Power 1
On Fri, 2020-08-14 at 17:59 -0500, Aaron Sawdey via Gcc-patches wrote:
Hi,
> This patch adds a few new instructions to inline expansion of
> memcpy/memmove. Generation of all these is controlled by
s/is/are/ ?
> the option -mblock-ops-unaligned-vsx which is set on by default if the
> target has
On Mon, 2020-08-24 at 14:39 -0700, Carl Love wrote:
> Segher:
>
> On Wed, 2020-08-19 at 15:16 -0500, Segher Boessenkool wrote:
> > On Wed, Aug 19, 2020 at 02:19:12PM -0500, Peter Bergner wrote:
> > > On 8/14/20 7:42 PM, Segher Boessenkool wrote:
> > > > I think your current code is fine; I hadn't
On Wed, 2020-08-26 at 22:43 -0400, Michael Meissner via Gcc-patches wrote:
> PowerPC: Change cmove function return to bool.
>
> In doing the other work for adding ISA 3.1 128-bit minimum, maximum, and
> conditional move support, I noticed the two functions that process conditional
> moves return '
On Wed, 2020-08-26 at 22:44 -0400, Michael Meissner via Gcc-patches wrote:
> PowerPC: Rename functions for min, max, cmove.
>
> This patch renames the functions that generate the ISA 3.0 C minimum, C
> maximum, and conditional move instructions to use a better name than just
> using
> a _p9 suffi
On Wed, 2020-08-26 at 22:45 -0400, Michael Meissner via Gcc-patches wrote:
> PowerPC: Add power10 xsmaxcqp/xsmincqp support.
>
> This patch adds support for the ISA 3.1 (power10) IEEE 128-bit "C" minimum and
> maximum functions. Because of the NaN differences, the built-in functions
> will
> onl
On Wed, 2020-08-26 at 22:46 -0400, Michael Meissner via Gcc-patches wrote:
> PowerPC: Add power10 xscmp{eq,gt,ge}qp support.
>
> This patch adds the conditional move support. In adding the conditional move
> support, the optimizers will be able to convert things like:
>
> a = (b > c) ? b :
On Fri, 2020-08-28 at 08:08 -0700, Carl Love wrote:
> GCC maintainers:
>
Hi,
> The defines for vec_popcnt, bvec_popcnth, vec_popcntw, vec_popcntd in
s/bvec/vec/
> gcc/config/rs6000/altivec.h are not listed in the Power 64-Bi ELF V2
> ABI specification revision 1.4, May 10, 2017. They are n
On Mon, 2020-08-31 at 04:06 -0500, Xiong Hu Luo via Gcc-patches wrote:
> vec_insert accepts 3 arguments, arg0 is input vector, arg1 is the value
> to be insert, arg2 is the place to insert arg1 to arg0. This patch adds
> __builtin_vec_insert_v4si[v4sf,v2di,v2df,v8hi,v16qi] for vec_insert to
> not
On Mon, 2020-08-31 at 14:43 +0800, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> Power9 supports vector with length in bytes load/store, this patch
> is to teach check_effective_target_vect_len_load_store to take it
> and its laters as effective vector with length targets.
>
> Also supplement the do
Hi,
This corrects an issue with the powerpc vector long long subtypes.
As reported by SjMunroe in PR96139. When building some code with -Wall
and attempting to print an element of a "long long vector" with a long long
printf format string, we will report a error because the vector sub-type
was
On Wed, 2020-09-02 at 05:13 -0500, Segher Boessenkool wrote:
> Hi Will,
>
> On Tue, Sep 01, 2020 at 09:00:20PM -0500, will schmidt wrote:
> > This corrects an issue with the powerpc vector long long
> > subtypes.
> > As reported by SjMunroe in PR96139. When building some code with
> > -Wall
> >
On Fri, 2020-09-04 at 03:47 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Sep 04, 2020 at 08:55:43AM +0200, Richard Biener wrote:
> > On Thu, Sep 3, 2020 at 8:10 PM Segher Boessenkool
> > wrote:
> > > On Thu, Sep 03, 2020 at 10:37:33AM -0500, will schmidt wrote:
> > > > On Wed, 2020-09-02 at
Hi,
As reported, the recently added pr96139 tests will fail on older targets
because the tests are missing the appropriate -mvsx or -maltivec options.
This adds the options and clarifies the dg-require statements.
sniff-regtested OK when specifying older targets o
On Fri, 2020-09-11 at 12:37 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Sep 11, 2020 at 09:44:54AM -0500, will schmidt wrote:
> > As reported, the recently added pr96139 tests will fail on older
> > targets
> > because the tests are missing the appropriate -mvsx or -maltivec
>
rs6000 - allow builtin initialization regardless of mask
Hi,
Disable the code that limits initialization of builtins based
on the rs6000_builtin_mask. This allows all built-ins to be
properly referenced when building code using #pragma for cpu
targets newer than what was specified by the -m
rs6000: Update bswap64-4 test to reflect actual results
Hi,
Update existing testcase powerpc/bswap64-4.c to
reflect that we generate ldbrx and stdbrx instructions
for newer cpu targets. This is in contrast to the
pair of lwbrx and stwbrx instructions that are
generated with older cpu targets.
Hi,
Comments inline.
(Taking a pass with focus on cosmetic stuff. This is intended to help Segher
focus on the harder parts :-) ).
On Mon, 2020-03-23 at 16:38 -0400, Michael Meissner via Gcc-patches wrote:
Subject: [Patch v327] set -mcprel by default ...
Include some powerpc or rs6000 referenc
On Mon, 2020-07-06 at 15:13 +0800, guojiufu via Gcc-patches wrote:
Hi,
Assorted comments below. thanks :-)
> For very small loops (< 6 insns), it would be fine to unroll 4
> times to use cache line better. Like below loops:
> `while (i) a[--i] = NULL; while (p < e) *d++ = *p++;`
>
> And
On Tue, 2020-07-07 at 16:19 -0700, Carl Love wrote:
> Segher:
>
> I have fixed the issues you mentioned in version 2. I also rebased the
> patch onto the latest mainline. This resulted in having to change
> FUTURE to P10 everywhere.
>
> I reran regression testing on Power 9 with no regression
On Tue, 2020-06-30 at 18:39 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Jun 30, 2020 at 12:57:45PM -0500, will schmidt wrote:
> > Add support for the vmsumudm instruction and tie it into the
> > vec_msum
> > built-in to support the variants of that built-in using vector
> > _int128 par
On Wed, 2020-07-08 at 09:22 -0700, Carl Love wrote:
> Will, Segher:
>
> I fixed up the patch based on Will's comments. I thought I had made
> and committed the fixes that Will caught, but no Sorry about
> that. I will get this right yet.
>
> Carl Love
> --
On Wed, 2020-07-08 at 12:58 -0700, Carl Love wrote:
> [PATCH 1/6] rs6000, Update support for vec_extract
Email subject needs to be updated too. This is at least correct in-
line. Here and subsequent messages in thread.
>
> -
> V4 changes
> rebased onto mainline
On Wed, 2020-07-08 at 12:59 -0700, Carl Love wrote:
> [PATCH 2/6] rs6000 Add vector insert builtin support
>
>
> V4 changes
> Rebased on mainline. Changed FUTURE to P10 as needed.
>
>
> V3 changes
>
> Replace spaces w
On Wed, 2020-07-08 at 12:59 -0700, Carl Love wrote:
> [PATCH 3/6] rs6000, Add vector replace builtin support
>
> --
> V4 Fixes:
>
>Rebased on mainline. Changed FUTURE to P10 in code and ChangeLog.
>Set DEBUG to 0 in vec-replace-word-runnable.c test program
On Wed, 2020-07-08 at 12:59 -0700, Carl Love wrote:
> [PATCH 4/6] rs6000, Add vector shift double builtin support
>
Nothing popped out at me for this patch.
lgtm
thanks
-Will
> --
> V4 Fixes:
>
>Rebased on mainline. Changed FUTURE to P10.
>Changed SLDB
On Wed, 2020-07-08 at 12:59 -0700, Carl Love wrote:
> [PATCH 5/6] rs6000, Add vector splat builtin support
>
> --
> V4 Fixes:
>
>Rebased on mainline. Changed FUTURE to P10.
>define_predicate "s32bit_cint_operand" removed unnecessary cast in
> definiti
On Wed, 2020-07-08 at 12:59 -0700, Carl Love wrote:
> [PATCH 6/6] rs6000 Add vector blend, permute builtin support
>
> --
> V4 Fixes:
>
>Rebased on mainline. Changed FUTURE to P10.
> -
>
> v3 fixes:
>Replace spaces with tabs in ChangeLog descripti
Hi,
We've got a scenario with a combination of old hardware, gcc-8 and
binutils where gcc will ICE during it's selftest. This ICE was exposed
when the builtin processing for better #pragma support was added, where
we no longer skip builtin initialization based on the current mask.
Per the
On Tue, 2020-05-26 at 11:12 -0500, will schmidt via Gcc-patches wrote:
> Hi,
>
> Add support for new instructions to test LSB by Byte.
>
> Tested on powerpc64le-unknown-linux-gnu with no
> regressions. (power7BE, power8LE, power8BE, power9LE).
Ping.
I note that I
[PATCH] RS6000 Add testlsbb by Byte operations
Hi,
Add support for new instructions to test LSB by Byte.
[v2] Additional updates per feedback. Including adding _all
to the internal name, typos and cosmetic fixups throughout, extraneous
-mvsx removed from tests.
V2 has completed tes
On Mon, 2020-07-27 at 09:14 -0500, Bill Schmidt wrote:
> From: Bill Schmidt
>
> 2020-07-26 Bill Schmidt
>
> * config/rs6000/rs6000-builtin-new.def: Add power9,
> power9-vector, and power9-64 builtins.
> ---
> gcc/config/rs6000/rs6000-builtin-new.def | 354
> ++
On Wed, 2020-03-25 at 23:15 -0500, luoxhu--- via Gcc-patches wrote:
> From: Xionghu Luo
>
Hi,
No real issues noted in my review. Patch is straighforward, just a
couple cosmetic comments inline below.
> This P1 bug is exposed by FRE refactor of r263875. Comparing the fre
> dump file shows no o
On Thu, 2020-03-26 at 05:06 -0500, luoxhu--- via Gcc-patches wrote:
> From: Xionghu Luo
>
> Remove split code from add3 to allow a later pass to split.
> This allows later logic to hoist out constant load in add
> instructions.
> In loop, lis+ori could be hoisted out to improve performance compar
On Thu, 2020-03-26 at 17:03 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Mar 24, 2020 at 01:26:25PM -0500, will schmidt wrote:
> > Update existing testcase powerpc/bswap64-4.c to
> > reflect that we generate ldbrx and stdbrx instructions
> > for newer cpu targets. This is in contrast to t
On Fri, 2020-03-27 at 21:31 -0400, Michael Meissner via Gcc-patches
wrote:
Hi,
A few cosmetic nits and comments sprinkled in below. I defer to
Segher for his approvals and comments. thanks,
-Will
> This is a revised version of the patch I posted on March 23rd. The
> changes are
> to updat
On Thu, 2020-03-26 at 14:23 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Mar 23, 2020 at 03:18:25PM -0500, will schmidt wrote:
> > Disable the code that limits initialization of builtins based
> > on the rs6000_builtin_mask. This allows all built-ins to be
> > properly referenced when bui
On Thu, 2020-04-02 at 20:36 -0400, Michael Meissner via Gcc-patches
wrote:
> Enable -mpcrel on PowerPC -mcpu=future ELF v2 systems, V3
>
Hi,
> This patch changes the default for -mcpu=future to be -mpcrel (i.e.
> use
> PC-relative addressing) if the ABI allows PC-relative relocations and
> the u
On Mon, 2020-04-06 at 12:52 -0400, Michael Meissner via Gcc-patches wrote:
Hi,
Just a single extra blank line below.
I'm still not a fan of the "Do not set..." comment, but will assume there
is history that necessitates the comment.
Other sections looked OK to me.
Over to Segher. :-)
Thanks,
On Thu, 2020-04-09 at 05:16 -0400, Michael Meissner via Gcc-patches
wrote:
> Backport PR target/93932 (variable vec_extract) to GCC 9
>
> This patch backports the fix for PR target/93932 from the current
> master branch
> to GCC 9. The patch for the master branch had to be adjusted due to
> using
[RFC][PR target/9] Compile time hog w/impossible asm constraint lra loop
Hi,
RFC for a bandaid/patch to partially address target PR/9.
This adds an escape condition from the forever loop where
LRA gets stuck while attempting to handle constraints from an
instruction that has previ
On Fri, 2020-04-10 at 18:00 -0500, acsawdey via Gcc-patches wrote:
> One of the things that address_to_insn_form() is used for is
> determining
> whether a PC-relative addressing instruction could be used. In
> particular predicate pcrel_external_address and function
> prefixed_paddi_p() both us
On Thu, 2020-04-16 at 08:21 -0500, Peter Bergner via Gcc-patches wrote:
> The ICE in PR93974 is caused by a bug in decompose address not being
> able to
> handle Altivec addresses the use AND: to strip off the bottom address
> bits.
> Rather than modify lra-constraints.c or rtlanal.c to solve this
On Wed, 2020-04-15 at 21:37 -0400, Michael Meissner via Gcc-patches wrote:
> Fix regression caused by PR target/93932 backport.
>
> When I back ported the fix for PR target/93932 to the GCC 9 branch, I put in
> an
> unintended regression when the GCC compiler is optimizing the vec_extract
> built
Hi,
On Mon, 2020-04-20 at 14:00 -0500, Aaron Sawdey via Gcc-patches wrote:
> For future architecture with prefix instructions, always use plq
> rather than lq for atomi load of quadword. Then we never have to
atomic :-)
> do the doubleword swap on little endian. Before this fix, -mno-pcrel
> w
On Wed, 2020-04-22 at 11:20 -0700, Carl Love wrote:
> GCC maintainers:
>
Hi,
> The following is a trivial patch to fix a comment describing the
> intrinsic function _mm_movemask_epi8. The comment was expanded to
> clarify the layout of the returned result.
Something seems wrong there, see be
On Wed, 2020-04-22 at 12:26 -0600, Jeff Law wrote:
> On Fri, 2020-04-10 at 16:40 -0500, will schmidt via Gcc-patches
> wrote:
> > [RFC][PR target/9] Compile time hog w/impossible asm constraint
> > lra loop
> >
> > Hi,
> > RFC for a bandaid/patch
On Thu, 2020-04-23 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
> A user reported that we are still referring to a public review
> draft of the ELFv2 ABI specification. Replace that by a permalink.
>
> Tested with "make pdf" and verified the link is hot. Is this okay
> for master?
>
Hi,
On Wed, 2020-04-22 at 07:59 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Apr 21, 2020 at 04:53:53PM -0500, Aaron Sawdey via Gcc-
> patches wrote:
> > For future architecture with prefix instructions, always use
> > plq/pstq
> > rather than lq/stq for atomic load of quadword. Then we never ha
On Mon, 2020-04-27 at 15:46 -0400, Michael Meissner via Gcc-patches
wrote:
> This patch adds supports in target-supports.exp for -mpcrel and
> -mprefixed.
>
> Patch #1 of 7.
Hi
Subject: Re: [PATCH] PowerPC -mcpu=future Patch 1 of 7, add target
supports for -mpcrel and -mprefixed
Squish that su
On Mon, 2020-04-27 at 15:48 -0400, Michael Meissner via Gcc-patches
wrote:
> Add tests for generating PLI/PADDI with -mcpu=future.
>
> This is patch #2 of 7. This patch was run on a little endian power8
> system
> running Linux and the patches succeeded.
>
> 2020-04-27 Michael Meissner
>
>
On Mon, 2020-04-27 at 15:53 -0400, Michael Meissner via Gcc-patches wrote:
> This patch adds a test that verifies that the compiler generates a prefixed
> load/store instruction where the compiler cannot generate the instruction
> directly because the offset is not a valid DS or DQ offset. A DS of
On Mon, 2020-04-27 at 15:57 -0400, Michael Meissner via Gcc-patches
wrote:
> This test validates that the compiler does not generate a prefixed
> load/store
> instruction with an update form. The prefixed load/store
> instructions do not
> have an update form.
>
> This is patch #4 of 7. This pat
On Mon, 2020-04-27 at 16:00 -0400, Michael Meissner via Gcc-patches
wrote:
> This patch adds tests for -mcpu=future generating prefixed load/store
> instructions with large numeric offsets.
>
> This is patch #5 of 7. This patch was tested on a little endian power8 system
> running Linux, and the
On Mon, 2020-04-27 at 16:01 -0400, Michael Meissner via Gcc-patches wrote:
> This patch adds PC-relative tests for -mcpu=future.
>
> This is patch #6 of 7. I have checked this on a little endian power8 system
> running Linux, and all tests passed. Can I check this into the GCC 10 trunk?
>
> 202
On Mon, 2020-04-27 at 16:04 -0400, Michael Meissner via Gcc-patches wrote:
> This patch adds a test for the case where we have prefixed load/store
> instructions, a large stack frame, and stack checking is enabled.
>
> This is patch #7 of 7. I have checked this patch on a little endian power8
> s
On Fri, 2020-05-01 at 09:42 -0700, Carl Love via Gcc-patches wrote:
> GCC maintainers:
>
Hi,
subject: Re: [PATCH] rs6000, fix vec_first_match_index for nulls
^ See if you can include the pr94833 string in the subject somewhere.
> The following patch fixes PR94833, vec_first_match_index doe
On Fri, 2020-05-01 at 10:48 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Apr 27, 2020 at 05:01:34PM -0500, will schmidt wrote:
> > On Mon, 2020-04-27 at 15:53 -0400, Michael Meissner via Gcc-patches
> > wrote:
> > > This patch adds a test that verifies that the compiler generates
> > > a pr
On Fri, 2020-05-01 at 17:02 -0500, Segher Boessenkool wrote:
> On Fri, May 01, 2020 at 03:54:26PM -0500, will schmidt wrote:
> > > The other way around :-) stfs is for single precision float
> > > ("float",
> > > in C), while stfd is for double precision float ("double", in C).
> >
> > I came up
101 - 200 of 285 matches
Mail list logo
