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
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
>
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. :-)
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
>
[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 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-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
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
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 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 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
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 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 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 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 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 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: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 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: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?
>
>
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 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 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 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
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
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.
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
>
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
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
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
On Tue, 2020-09-15 at 10:49 +0930, Alan Modra via Gcc-patches wrote:
> The existing "case AND" in this function is not sufficient for
> optabs.c:avoid_expensive_constant usage, where the AND is passed in
> outer_code.
>
> * config/rs6000/rs6000.c (rs6000_rtx_costs): Move costing for
>
On Tue, 2020-09-15 at 10:49 +0930, Alan Modra via Gcc-patches wrote:
> This patch series fixes a number of issues in rs6000_rtx_costs, the
> aim being to provide costing somewhat closer to reality. Probably
> the
> most important patch of the series is patch 4, which just adds a
> comment.
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
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
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
On Thu, 2020-10-08 at 09:36 +1030, Alan Modra via Gcc-patches wrote:
> Implement more two insn constants. rotate_and_mask_constant covers
> 64-bit constants that can be formed by rotating a 16-bit signed
> constant, rotating a 16-bit signed constant masked on left or right
> (rldicl and rldicr),
On Thu, 2020-10-08 at 09:27 +1030, Alan Modra via Gcc-patches wrote:
> The aim of this patch is to make rtx_costs for SETs closer to
> insn_cost for SETs. One visible effect on powerpc code is increased
> if-conversion.
>
> * config/rs6000/rs6000.c (rs6000_rtx_costs): Reduce cost of SET
>
On Mon, 2020-10-05 at 11:52 -0700, Carl Love wrote:
> Will, Segher:
>
> Patch 4 adds the vector 128-bit integer shift instruction support for
> the V1TI type.
>
> The changes from the previous version include:
>
> Fixed up the change log entry issues noted by Will.
>
> Regression tests reran
On Mon, 2020-10-05 at 11:52 -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
On Mon, 2020-10-05 at 11:52 -0700, Carl Love wrote:
> Will, Segher:
>
> Add support for converting to/from 128-bit integers and 128-bit
> decimal floating point formats.
>
> The updates from the previous version of the patch:
>
> Just a fix for the change log per Will's comments.
>
> No
Hi,
Rename our BU_P10_MISC_2 built-in define macro to be
BU_P10_POWERPC64_MISC_2. This more accurately reflects
that the macro includes the RS6000_BTM_POWERPC64 entry
that is not present in the other BU_P10_MISC macros,
and matches the style we used for the P7 equivalent.
Should be
On Mon, 2020-10-05 at 17:23 -0300, Tulio Magno Quites Machado Filho via
Gcc-patches wrote:
> Ping?
+cc Segher :-)
>
> Tulio Magno Quites Machado Filho via Gcc-patches
> writes:
>
> > Replace them with a whitespace in order to avoid artifacts in the HTML
> > document.
> >
> > 2020-08-19
On Mon, 2020-10-05 at 11:52 -0700, Carl Love wrote:
> Will and Segher:
>
> This is the rest of the second patch which adds the 128-bit integer
> support for divide, modulo, shift, compare of 128-bit
> integers instructions and builtin support.
>
> In the last round of changes, the flag for the
On Mon, 2020-10-05 at 11:51 -0700, Carl Love wrote:
> Will, Segher:
>
> Patch 1, adds the 128-bit sign extension instruction support and
> corresponding builtin support.
>
> I updated the change log per the comments from Will.
>
> Patch has been retested on Power 9 LE.
>
> Pet me know if it
On Mon, 2020-10-05 at 11:52 -0700, Carl Love wrote:
> Will, Segher:
>
>
>
> The following changes were made from the previous version:
>
> Per Will's comments, I split the bug fix from patch 2 into a separate
> patch. This patch is the bug fix for the vec_rlnm builtin.
I recommend trying to
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
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
>
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 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 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
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,
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
On Mon, 2020-09-21 at 16:56 -0700, Carl Love wrote:
> Segher, Will:
>
> Patch 1, adds the 128-bit sign extension instruction support and
> corresponding builtin support.
>
> No changes from the previous version.
>
> The patch has been tested on
>
> powerpc64le-unknown-linux-gnu (Power 9 LE)
On Mon, 2020-09-21 at 16:56 -0700, Carl Love wrote:
> Segher, Will:
>
> Add support for converting to/from 128-bit integers and 128-bit
> decimal floating point formats.
A more wordy blurb here clarifying what the patch does would be useful.
i.e. this adds support for dcffixqq and dctfixqq
On Mon, 2020-09-21 at 16:56 -0700, Carl Love wrote:
> Will, Segher:
>
> Add support for divide, modulo, shift, compare of 128-bit
> integers instructions and builtin support.
>
> The following are the changes from the previous version of the patch.
>
> The TARGET_TI_VECTOR_OPS was removed per
On Mon, 2020-09-21 at 16:57 -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
On Mon, 2020-09-21 at 16:56 -0700, Carl Love wrote:
> Segher, Will:
>
> Patch 4 adds the vector 128-bit integer shift instruction support for
> the V1TI type.
>
> The following changes were made from the previous version.
>
> Renamed VSX_TI to VEC_TI, put def in vector.md. Didn't get it
>
[PATCH, rs6000] correct an erroneous blip in the BU_P10_MISC define
Hi,
We have extraneous BTM entry (RS6000_BTM_POWERPC64) in the define for
our P10 MISC 2 builtin definition. This does not exist for the '0',
'1' or '3' definitions. It appears to me that this was erroneously
copied from
On Thu, 2020-09-24 at 19:40 -0500, Segher Boessenkool wrote:
> On Thu, Sep 24, 2020 at 11:04:38AM -0500, will schmidt wrote:
> > [PATCH 2/2, rs6000] VSX load/store rightmost element operations
> >
> > Hi,
> > This adds support for the VSX load/store rightmost element
> > operations.
> > This
On Fri, 2020-09-25 at 12:36 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Sep 24, 2020 at 03:35:24PM -0500, will schmidt wrote:
> > We have extraneous BTM entry (RS6000_BTM_POWERPC64) in the
> > define for
> > our P10 MISC 2 builtin definition. This does not exist for the
> > '0',
> >
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
On Fri, 2020-09-04 at 12:52 -0300, Raoni Fassina Firmino via Gcc-patches wrote:
> Changes since v1[1]:
> - Fixed english spelling;
> - Fixed code-style;
> - Changed match operand predicate in feclearexcept and feraiseexcept;
> - Changed testcase options;
> - Minor changes in test code to
[PATCH, rs6000] int128 sign extention instructions (partial prereq)
Hi
This is a sub-set of the 128-bit sign extension support patch series
that I believe will be fully implemented in a subsequent patch from Carl.
This is a necessary pre-requisite for the vector-load/store rightmost
element
[PATCH 2/2, rs6000] VSX load/store rightmost element operations
Hi,
This adds support for the VSX load/store rightmost element operations.
This includes the instructions lxvrbx, lxvrhx, lxvrwx, lxvrdx,
stxvrbx, stxvrhx, stxvrwx, stxvrdx; And the builtins
vec_xl_sext() /* vector load sign extend
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:
> 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 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 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 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.
On Thu, 2020-10-22 at 18:03 -0400, Michael Meissner via Gcc-patches wrote:
> PowerPC: Map IEEE 128-bit long double built-in functions
>
> This patch is revised from the first and second versions of the patch posted.
> It now uses the names that are not in the user's namespace (i.e. __sinieee128
>
On Thu, 2020-10-22 at 18:05 -0400, Michael Meissner via Gcc-patches wrote:
> PowerPC: Add -mno-gnu-attributes to ibm-ldouble.o.
>
> I have split all of these patches into separate patches to hopefully get them
> into the tree.
>
> This patch is split off from the patch adding __float128 <->
On Thu, 2020-10-22 at 18:15 -0400, Michael Meissner via Gcc-patches wrote:
> PowerPC: Allow C/C++ to change long double type on GLIBC 2.32.
>
> This is a new patch. It turns off the warning about switching the long double
> type via compile line if the GLIBC is 2.32 or newer. It only does this
[PATCH, rs6000] improve vec_ctf invalid parameter handling.
Hi,
Per PR91903, GCC ICEs when we attempt to pass a variable
(or out of range value) into the vec_ctf() builtin. Per
investigation, the parameter checking exists for this
builtin with the int types, but was missing for
the long long
On Thu, 2020-10-22 at 18:12 -0400, Michael Meissner via Gcc-patches wrote:
> PowerPC: Use __float128 instead of __ieee128 in tests.
>
> I have split all of these patches into separate patches to hopefully get them
> into the tree.
>
> Two of the tests used the __ieee128 keyword instead of
On Wed, 2020-10-28 at 21:20 +1030, Alan Modra via Gcc-patches wrote:
> Otherwise some versions of dejagnu go ahead and run the vsx tests
> below when they should not. To best cope with older dejagnu, put
> "run" before "compile", the idea being that if the second dg-do always
> wins then that
On Thu, 2020-10-22 at 18:09 -0400, Michael Meissner via Gcc-patches wrote:
> PowerPC: Update IEEE 128-bit built-ins for long double is IEEE 128-bit.
"for when .."
>
> I have split all of these patches into separate patches to hopefully get them
> into the tree.
>
> This patch adds long double
On Thu, 2020-10-22 at 18:11 -0400, Michael Meissner via Gcc-patches wrote:
> PowerPC: Update __float128 and __ibm128 error messages.
>
> I have split all of these patches into separate patches to hopefully get them
> into the tree.
>
> This patch attempts to make the error messages for
On Thu, 2020-10-22 at 18:10 -0400, Michael Meissner via Gcc-patches wrote:
> PowerPC: Use __builtin_pack_ieee128 if long double is IEEE 128-bit.
>
> I have split all of these patches into separate patches to hopefully get them
> into the tree.
>
> This patch changes the __ibm128 emulator to use
On Thu, 2020-10-22 at 18:06 -0400, Michael Meissner via Gcc-patches wrote:
> PowerPC: Add __float128 conversions to/from Decimal.
>
> I have split all of these patches into separate patches to hopefully get them
> into the tree.
>
> This patch adds the various decimal to/from IEEE 128-bit
On Thu, 2020-10-22 at 18:07 -0400, Michael Meissner via Gcc-patches wrote:
> PowerPC: Update long double IEEE 128-bit tests.
>
> I have split all of these patches into separate patches to hopefully get them
> into the tree.
>
> This patch fixes 3 tests in the testsuite that fail if long double
On Thu, 2020-10-22 at 18:08 -0400, Michael Meissner via Gcc-patches wrote:
> PowerPC: Map q built-ins to *l instead of *f128 if IEEE 128-bit long double.
>
> I have split all of these patches into separate patches to hopefully get them
> into the tree.
>
> If we map nanq to nanf128 when long
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 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
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
Hi,
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 parameters.
vector _uint128_t vec_msum (vector unsigned long long,
vector unsigned long long,
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
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
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
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
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
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
1 - 100 of 902 matches
Mail list logo
