2020-06-17 Bill Schmidt
* config/rs6000/rs6000-gen-builtins.c (MAXBIFSTANZAS): New defined
constant.
(bif_stanzas): New filescope variable.
(curr_bif_stanza): Likewise.
(fnkinds): New enum.
(typelist): New struct.
(attrinfo): Likewise.
2020-06-17 Bill Schmidt
* config/rs6000/rs6000-gen-builtins.c (MININT): New defined
constant.
(exit_codes): New enum.
(consume_whitespace): New function.
(advance_line): Likewise.
(safe_inc_pos): Likewise.
(match_identifier): Likewise.
This patch adds a tiny subset of the built-in and overload descriptions.
2020-06-17 Bill Schmidt
* config/rs6000/rs6000-builtin-new.def: New.
* config/rs6000/rs6000-overload.def: New.
---
gcc/config/rs6000/rs6000-builtin-new.def | 178 +++
2020-06-17 Bill Schmidt
* config/rs6000/rs6000-gen-builtins.c (restriction): New enum.
(typeinfo): Add restriction field.
(match_const_restriction): Implement.
---
gcc/config/rs6000/rs6000-gen-builtins.c | 136
1 file changed, 136 insertions(+)
2020-06-17 Bill Schmidt
* config/rs6000/rs6000-gen-builtins.c (bif_file): New filescope
variable.
(ovld_file): Likewise.
(header_file): Likewise.
(init_file): Likewise.
(defines_file): Likewise.
(pgm_path): Likewise.
(bif_path):
2020-06-17 Bill Schmidt
* config/rs6000/rs6000-gen-builtins.c (match_basetype):
Implement.
---
gcc/config/rs6000/rs6000-gen-builtins.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/gcc/config/rs6000/rs6000-gen-builtins.c
2020-06-17 Bill Schmidt
* config/rs6000/rs6000-gen-builtins.c: New.
---
gcc/config/rs6000/rs6000-gen-builtins.c | 142
1 file changed, 142 insertions(+)
create mode 100644 gcc/config/rs6000/rs6000-gen-builtins.c
diff --git
On Tue, 2020-05-26 at 11:12 -0500, will schmidt 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).
>
> [gcc]
>
> 2020-05-26 Will Schmidt
>
> *
On Tue, 2020-06-16 at 13:59 -0500, Peter Bergner wrote:
> On 6/15/20 5:43 PM, will schmidt wrote:
> > On Mon, 2020-06-15 at 14:56 -0500, Peter Bergner via Gcc-patches wrote:
> > > * config/rs6000/rs6000-cpus.def (OTHER_FUTURE_MASKS): Add
> > > OPTION_MASK_MMA.
> > > (POWERPC_MASKS):
On Mon, 2020-06-15 at 16:38 -0700, Carl Love via Gcc-patches wrote:
> v2 changes:
>
>Updated ChangeLog per comments.
>
>define_expand "xxpermx", Updated implementation to use XOR
Unclear.. Updated implementation of the xxpermx ?
>(icode == CODE_FOR_xxpermx, fix comments and
On Mon, 2020-06-15 at 16:38 -0700, Carl Love via Gcc-patches wrote:
> v2 changes:
>
> change log fixes
>
> gcc/config/rs6000/altivec changed name of define_insn and define_expand
> for vxxspltiw... to xxspltiw... Fixed spaces in
> gen_xxsplti32dx_v4sf_inst (operands[0], GEN_INT
On Mon, 2020-06-15 at 16:38 -0700, Carl Love via Gcc-patches wrote:
> v2 fixes:
>
> change logs redone
>
> gcc/config/rs6000/rs6000-call.c - added spaces before parenthesis around
> args.
>
> -
> GCC maintainers:
>
> The
On Mon, 2020-06-15 at 16:37 -0700, Carl Love via Gcc-patches wrote:
> v2 changes
>
> Fix change log entry for config/rs6000/altivec.h
>
> Fix change log entry for config/rs6000/rs6000-builtin.def
>
> Fix change log entry for config/rs6000/rs6000-call.c
>
> vsx.md: Fixed if (BYTES_BIG_ENDIAN)
On Mon, 2020-06-15 at 16:37 -0700, Carl Love via Gcc-patches wrote:
> v2 fixes:
>
> change log entries config/rs6000/vsx.md, config/rs6000/rs6000-builtin.def,
> config/rs6000/rs6000-call.c.
>
> gcc/config/rs6000/rs6000-call.c: fixed if check for 3rd arg between 0 and 3
>
On Mon, 2020-06-15 at 16:37 -0700, Carl Love via Gcc-patches wrote:
> v2 changes
>
> config/rs6000/altivec.md log entry for move from changed as
> suggested.
>
> config/rs6000/vsx.md log entro for moved to here changed as
> suggested.
>
> define_mode_iterator VI2 also moved, included in both
[PATCH v2, PR target/94954] Fix wrong codegen for vec_pack_to_short_fp32()
builtin
Hi,
Fix codegen for builtin vec_pack_to_short_fp32. This includes adding
a define_insn for xvcvsphp, and adding a new define_expand for
convert_4f32_8f16.
[v2]
Comment on altivec.md
On Mon, 2020-06-15 at 14:59 -0500, Peter Bergner via Gcc-patches wrote:
> This patch adds the testsuite test cases for all of the MMA built-
> ins.
>
> This patch plus patch1 and patch2 passed bootstrap and regtesting
> with no
> regressions on both powerpc64le-linux and powerpc64-linux. Ok for
On Mon, 2020-06-15 at 14:58 -0500, Peter Bergner via Gcc-patches wrote:
> This patches adds the actual MMA built-ins. The MMA accumulators are
> INOUT
> operands for most MMA instructions, but they are also very expensive
> to
> move around. For this reason, we have implemented a built-in API
>
On Mon, 2020-06-15 at 14:56 -0500, Peter Bergner via Gcc-patches wrote:
> This patch adds the new -mmma option as well as the initial MMA
> support,
> which includes the target specific __vector_pair and __vector_quad
> types,
> the POImode and PXImode partial integer modes they are mapped to, and
On Fri, 2020-06-12 at 18:31 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Jun 11, 2020 at 11:22:33PM -0500, will schmidt wrote:
> > Fix codegen implementation for the builtin
> > vec_pack_to_short_fp32.
> > +;; Convert two vector F32 to packed vector f16.
> > +(define_expand
On Fri, 2020-06-12 at 10:24 -0400, David Edelsohn wrote:
> Hi, Will
Hi,
>
> On Fri, Jun 12, 2020 at 12:22 AM will schmidt <
> will_schm...@vnet.ibm.com> wrote:
> >
> >
> > Hi,
> > Fix codegen implementation for the builtin
> > vec_pack_to_short_fp32.
> >
> > Regtests are underway
Hi,
Fix codegen implementation for the builtin vec_pack_to_short_fp32.
Regtests are underway against powerpc64 (power7be,power8le,power9le).
(this is a power9 builtin, so should be a noop for most of those).
OK for trunk and backports?
Thanks
-Will
[gcc]
On Tue, 2020-06-09 at 17:01 -0700, Carl Love wrote:
> Segher:
>
> So I have been looking at the predicate definitions that I had
> created.
>
> On Fri, 2020-06-05 at 16:28 -0500, Segher Boessenkool wrote:
> > > +;; Return 1 if op is a 32-bit constant signed integer
> > > +(define_predicate
On Tue, 2020-06-09 at 01:00 +, Segher Boessenkool wrote:
> Some testcases failed (esp. with --with-cpu=power9) after my change
> to
> prefer xxperm over vperm when all else is equal. Fix that. (This
> also
> tightens the relevant REs somewhat).
>
> Tested on way too many configurations.
On Mon, 2020-06-01 at 16:01 -0400, Michael Meissner via Gcc-patches
wrote:
> These 3 patches add support for some new instructions in the 'future'
> processor.
>
> The first patch adds support for the new byte swap instructions that
> byte swap
> valies in the GPRs.
values
>
> The second patch
On Mon, 2020-06-01 at 16:01 -0400, Michael Meissner via Gcc-patches wrote:
> Add support for the new IEEE 128-bit minimum, maximum, and set compare mask
> instructions when -mcpu=future was used.
>
> gcc/
> 2020-06-01 Michael Meissner
>
> * config/rs6000/rs6000.c
On Mon, 2020-06-01 at 16:01 -0400, Michael Meissner via Gcc-patches
wrote:
> Add support for generating BRH/BRW/BRD when -mcpu=future is used.
>
Hi,
> gcc/
> 2020-06-01 Michael Meissner
>
> * config/rs6000/rs6000.md (bswaphi2_reg): If -mcpu=future,
> generate the BRH
On Mon, 2020-06-01 at 15:53 -0400, Michael Meissner via Gcc-patches
wrote:
> This thread adds seven patches to add tests for the -mcpu=future code
> generation. These patches are an update to the patches I sent out in
> April.
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544653.html
On Mon, 2020-06-01 at 15:53 -0400, Michael Meissner via Gcc-patches wrote:
> These tests make sure that PC-relative variant is generated for -mcpu=future
> on
> systems that support PC-relative addressing.
>
> 2020-06-01 Michael Meissner
>
> * gcc.target/powerpc/prefix-pcrel-dd.c: New
On Fri, 2020-05-22 at 13:27 -0700, Carl Love wrote:
> GCC maintainers:
>
> The following patch adds support for builtins
> vec_genbm(), vec_genhm(),
> vec_genwm(), vec_gendm(), vec_genqm(), vec_cntm(), vec_expandm(),
> vec_extractm(). Support for instructions mtvsrbm, mtvsrhm, mtvsrwm,
>
Hi,
Add support for new instructions to test LSB by Byte.
Tested on powerpc64le-unknown-linux-gnu with no
regressions. (power7BE, power8LE, power8BE, power9LE).
[gcc]
2020-05-26 Will Schmidt
* config/rs6000/altivec.h (vec_test_lsbb_all_ones): New define.
From: Kelvin Nilsen
Add new insns vextdu[bhw]vlx, vextddvlx, vextdu[bhw]vhx, and
vextddvhx, along with built-in access and overloaded built-in
access to these insns.
Changes from previous patch:
* Removed the int iterators
* Created separate expansions and insns
vextractl
On 5/12/20 1:21 PM, Segher Boessenkool wrote:
Hi!
On Mon, May 11, 2020 at 09:56:14PM -0500, Bill Schmidt wrote:
On 5/11/20 9:48 AM, David Edelsohn wrote:
On Sun, May 10, 2020 at 9:14 AM Bill Schmidt
wrote:
* config/rs6000/altivec.md (UNSPEC_EXTRACTL): New constant.
On 5/12/20 4:54 AM, Segher Boessenkool wrote:
Hi!
Looks fine to me... Just the same generic things as before, things we
can improve later, not even limited to this series:
On Sat, May 09, 2020 at 08:16:26AM -0500, Bill Schmidt wrote:
* config/rs6000/altivec.md (UNSPEC_VSTRIR): New
On 5/11/20 9:48 AM, David Edelsohn wrote:
On Sun, May 10, 2020 at 9:14 AM Bill Schmidt wrote:
From: Kelvin Nilsen
Add new insns vextdu[bhw]vlx, vextddvlx, vextdu[bhw]vhx, and
vextddvhx, along with built-in access and overloaded built-in
access to these insns.
Bootstrapped and tested on
On 5/11/20 7:16 AM, Segher Boessenkool wrote:
Hi!
On Sat, May 09, 2020 at 08:08:34PM -0500, Bill Schmidt wrote:
I should have noticed this patch before submitting Kelvin's earlier
related patches, sorry. I think it should still be fine to apply
the patches in order, but if you'd like me to
On 5/11/20 5:21 AM, Segher Boessenkool wrote:
Hi!
On Sat, May 09, 2020 at 12:05:08PM -0500, Bill Schmidt wrote:
From: Carl Love
Add support for xxgenpcv[dw]m, along with individual and overloaded
built-in functions for access.
(xxgenpcvm_): New insn.
(xxgenpcvm): New
On 5/8/20 6:51 PM, Segher Boessenkool wrote:
On Fri, May 08, 2020 at 08:17:18AM -0500, Bill Schmidt wrote:
From: Kelvin Nilsen
Add support for new scalar instructions for counting leading or
trailing zeros under control of a bitmask.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu
On 5/8/20 3:47 PM, Segher Boessenkool wrote:
Hi,
On Thu, May 07, 2020 at 09:29:03PM -0500, Bill Schmidt wrote:
diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
index 5ef4889ba55..33ba57855bc 100644
--- a/gcc/config/rs6000/altivec.md
+++ b/gcc/config/rs6000/altivec.md
@@
From: Kelvin Nilsen
Add new insns vextdu[bhw]vlx, vextddvlx, vextdu[bhw]vhx, and
vextddvhx, along with built-in access and overloaded built-in
access to these insns.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions, using a Power9 configuration. Is this okay for
From: Kelvin Nilsen
Changes to the built-in specification occurred after early patches
added support for these. The name of vec_clzm became vec_cntlzm,
and vec_ctzm became vec_cnttzm. Four of the overloaded forms of
vec_gnb were removed, and the fourth argument redefined as an
unsigned int,
From: Carl Love
Add support for xxgenpcv[dw]m, along with individual and overloaded
built-in functions for access.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions, using a POWER9 compiler. Is this okay for master?
Thanks,
Bill
[gcc]
2020-05-09 Carl Love
From: Kelvin Nilsen
Adds new instructions vstribr, vstrihr, vstribl, and vstrihl, with
overloaded built-in support.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions, using a compiler configured for Power9. Is this okay
for master?
Thanks,
Bill
[gcc]
2020-05-08
From: Kelvin Nilsen
Add the xxeval insn and access it via the vec_ternarylogic built-in
function. As part of this, add support to the built-in function
infrastructure for functions that take four arguments.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions, using a
From: Kelvin Nilsen
Add scalar instructions for parallel bit deposit and extract, with
built-in function support.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions. Is this okay for master?
Thanks,
Bill
[gcc]
2020-05-08 Kelvin Nilsen
*
Please ignore, I sent the wrong ChangeLog. Will try again momentarily.
Sorry,
Bill
On 5/8/20 3:05 PM, Bill Schmidt via Gcc-patches wrote:
From: Kelvin Nilsen
Add scalar instructions for parallel bit deposit and extract, with
built-in function support.
Bootstrapped and tested on powerpc64le
From: Kelvin Nilsen
Add scalar instructions for parallel bit deposit and extract, with
built-in function support.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions. Is this okay for master?
Thanks,
Bill
[gcc]
2020-05-08 Kelvin Nilsen
*
On 5/8/20 2:00 PM, Segher Boessenkool wrote:
On Thu, May 07, 2020 at 09:11:32PM -0500, Bill Schmidt wrote:
From: Kelvin Nilsen
Add support for new vclzdm and vctzdm vector instructions that
count leading and trailing zeros under control of a mask.
Bootstrapped and tested on
From: Kelvin Nilsen
Add new vector instructions to clear leftmost and rightmost bytes.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions. Is this okay for master?
Thanks,
Bill
[gcc]
2020-05-08 Kelvin Nilsen
* config/rs6000/altivec.h (vec_clrl): New
From: Kelvin Nilsen
Add support for new scalar instructions for counting leading or
trailing zeros under control of a bitmask.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions. Is this okay for master?
Thanks,
Bill
[gcc]
2020-05-08 Kelvin Nilsen
*
From: Kelvin Nilsen
Add the new vector centrifuge-doubleword instruction and built-in
function access.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions. Is this okay for master?
Thanks,
Bill
[gcc]
2020-05-08 Kelvin Nilsen
* config/rs6000/altivec.h
From: Kelvin Nilsen
Add the centrifuge-doubleword instruction and built-in access.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions. Is this okay for master?
Thanks,
Bill
[gcc]
2020-05-08 Kelvin Nilsen
* config/rs6000/rs6000-builtin.def
From: Kelvin Nilsen
Add support for the vgnb instruction, which gathers every Nth bit
per vector element.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions. Is this okay for master?
Thanks,
Bill
[gcc]
2020-05-07 Kelvin Nilsen
Bill Schmidt
From: Kelvin Nilsen
Add support for the vpdepd and vpextd instructions which perform
vector parallel bit deposit and vector parallel bit extract.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions. Is this okay for master?
Thanks,
Bill
2020-05-07 Kelvin Nilsen
From: Kelvin Nilsen
Add support for new vclzdm and vctzdm vector instructions that
count leading and trailing zeros under control of a mask.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions. Is this okay for master?
Thanks,
Bill
[gcc]
2020-05-07 Kelvin Nilsen
From: Kelvin Nilsen
Dejagnu targets for these.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions. Is this okay for master?
Patch shepherded by Bill Schmidt on behalf of Kelvin Nilsen.
Thanks!
Bill
2020-03-04 Kelvin Nilsen
*
On 5/6/20 6:48 PM, Segher Boessenkool wrote:
On Wed, May 06, 2020 at 03:41:35PM -0500, Bill Schmidt wrote:
For all of these, I forgot to mention that they have been bootstrapped
and tested on powerpc64le-unknown-linux-gnu with no regressions. Are
these okay for trunk, after GCC 10 is fully
For all of these, I forgot to mention that they have been bootstrapped
and tested on powerpc64le-unknown-linux-gnu with no regressions. Are
these okay for trunk, after GCC 10 is fully released?
Thanks,
Bill
On 5/6/20 3:31 PM, Bill Schmidt via Gcc-patches wrote:
*** BLURB HERE ***
Bill
*** BLURB HERE ***
Bill Schmidt (4):
Add insns for setbc and setbcr
Add tests for setbc and setbcr
Add insns for setnbc and setnbcr
Add tests for setnbc and setnbcr
gcc/config/rs6000/rs6000.md | 100 +---
gcc/testsuite/gcc.target/powerpc/setbc.h| 27
2020-05-06 Segher Boessenkool
* gcc.target/powerpc/setnbc.h: New.
* gcc.target/powerpc/setnbceq.c: New.
* gcc.target/powerpc/setnbcge.c: New.
* gcc.target/powerpc/setnbcgt.c: New.
* gcc.target/powerpc/setnbcle.c: New.
*
2020-05-06 Segher Boessenkool
* gcc.target/powerpc/setbc.h: New.
* gcc.target/powerpc/setbceq.c: New.
* gcc.target/powerpc/setbcge.c: New.
* gcc.target/powerpc/setbcgt.c: New.
* gcc.target/powerpc/setbcle.c: New.
* gcc.target/powerpc/setbclt.c:
New instructions setbc and setbcr. setbc sets a GPR to 1 if some
condition register bit is set, and 0 otherwise; setbcr does it the
other way around.
2020-05-06 Segher Boessenkool
* config/rs6000/rs6000.md (setbc_signed_): New
define_insn.
(*setbcr_signed_): Likewise.
setnbc[r] is like setbc[r], but it writes -1 instead of 1 to the GPR.
2020-05-06 Segher Boessenkool
* config/rs6000/rs6000.md (*setnbc_signed_): New
define_insn.
(*setnbcr_signed_): New define_insn.
(*neg_eq_): Avoid for TARGET_FUTURE; add missing && 1.
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
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
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
On 4/22/20 1:20 PM, Carl Love wrote:
GCC maintainers:
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.
The patch does not make any functional changes.
Please let me
On 4/28/20 10:42 AM, Jakub Jelinek wrote:
On Tue, Apr 28, 2020 at 10:16:24AM -0500, Bill Schmidt via Gcc-patches wrote:
I think this looks good. My only comment would be to please add some
comments in the test cases about the purpose, or at least to explain
the regexes in the scan-assembler
On 4/28/20 6:38 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
Ok, I've tried:
struct X { };
struct Y { int : 0; };
struct Z { int : 0; Y y; };
struct U : public X { X q; };
struct A { float a, b, c, d; };
struct B : public X { float a, b, c, d; };
struct C : public Y { float a, b, c, d; };
Jakub, thanks for continuing to track down and fix all these cases.
I think this looks good. My only comment would be to please add some
comments in the test cases about the purpose, or at least to explain
the regexes in the scan-assembler-* directives, to save us all some
mental cycles in the
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
>
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?
>
>
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 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
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
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: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
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
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 ok
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?
Thanks,
Bill
2020-04-24 Bill Schmidt
* gcc/doc/extend.texi (PowerPC
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 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
On 4/22/20 11:49 AM, Jakub Jelinek wrote:
On Wed, Apr 22, 2020 at 11:24:09AM -0500, Bill Schmidt wrote:
Hm, but this patch violates the ELFv2 ABI as written. The ABI includes:
"Floating-point and vector aggregates that contain padding words and
integer fields with a width of 0 should not be
On 4/22/20 8:11 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
As mentioned in the PR and on IRC, the recently added struct-layout-1.exp
new tests FAIL on powerpc64le-linux (among other targets).
FAIL: tmpdir-g++.dg-struct-layout-1/t032 cp_compat_x_tst.o-cp_compat_y_tst.o
execute
FAIL:
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
>
On 4/17/20 1:53 AM, Richard Biener wrote:
Yeah well, but RTL is not in SSA form and there's no RTL IL verification
in place to track degradation. And we even work in the opposite way
when expanding to RTL from SSA, coalescing as much as we can ...
Which is itself problematic, introducing
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
>
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 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
[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
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
>
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. :-)
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
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
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
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
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
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
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
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.
801 - 900 of 902 matches
Mail list logo
