On Mon, 2022-10-17 at 13:08 -0500, Segher Boessenkool wrote:
> On Mon, Sep 19, 2022 at 11:13:20AM -0500, will schmidt wrote:
> > The _ARCH_PWR8 define is conditional on TARGET_DIRECT_MOVE,
> > and can be disabled by dependent options when it should not be.
> > This manifests
On Mon, 2022-10-17 at 10:32 -0500, Segher Boessenkool wrote:
> Hi!
>
> Everything Ke Wen said. Some more commments / hints:
Thanks for the reviews. :-)
I'll rework things and repost 'soon'.
Thanks
-WIll
Ping.
On Mon, 2022-09-19 at 11:13 -0500, will schmidt wrote:
> [PATCH, rs6000] Split TARGET_POWER8 from TARGET_DIRECT_MOVE [PR101865]
>
> Hi,
> The _ARCH_PWR8 define is conditional on TARGET_DIRECT_MOVE,
> and can be disabled by dependent options when it should not be.
>
[PATCH, rs6000] Fix addg6s builtin with long long parameters. (PR100693)
Hi,
As reported in PR 100693, attempts to use __builtin_addg6s
with long long arguments result in truncated results.
Since the int and long long types can be coerced into each other,
(documented further near the rs6000-c.c
On Fri, 2022-09-30 at 09:20 +0200, Jakub Jelinek via Gcc-patches wrote:
> On Wed, Sep 28, 2022 at 08:19:43PM +0200, Jakub Jelinek via Gcc-
> patches wrote:
> > Another case are the following 3 snippets:
> > # if !__GNUC_PREREQ (7, 0) || defined __cplusplus
> > # error "_Float128X supported but n
On Tue, 2022-09-20 at 16:14 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Sep 19, 2022 at 06:19:15PM -0500, will schmidt wrote:
> > This is the first of a batch of changes that eliminate a number
> > of define TARGET_foo entries we have collected over
[PATCH, rs6000] Eliminate TARGET_CTZ,TARGET_FCTIDZ,FCTIWUZ defines
Hi,
This is the first of a batch of changes that eliminate a number
of define TARGET_foo entries we have collected over time.
TARGET_CTZ is defined as TARGET_MODULO, and has a low number
of uses. References to TARGET_CTZ should
[PATCH, rs6000] Split TARGET_POWER8 from TARGET_DIRECT_MOVE [PR101865]
Hi,
The _ARCH_PWR8 define is conditional on TARGET_DIRECT_MOVE,
and can be disabled by dependent options when it should not be.
This manifests in the issue seen in PR101865 where -mno-vsx
mistakenly disables _ARCH_PWR8.
This
[PATCH, rs6000] Tests of ARCH_PWR8 and -mno-vsx option.
Hi,
This adds an assortment of tests to exercise the -mno-vsx option and
confirm the impacts on the ARCH_PWR8 define.
These are based on and inspired by PR 101865, which
reports that _ARCH_PWR8 is disabled when -mno-vsx
is passed on the com
[PATCH, rs6000, v2] Cleanup some vstrir define_expand naming inconsistencies
Hi,
This cleans up some of the naming around the vstrir and vstril
instruction definitions, with some cosmetic changes for consistency.
No functional changes.
Regtested just in case, no regressions.
[V2]
Used 'direct'
[PATCH, rs6000, v2] Additional cleanup of rs6000_builtin_mask
Hi,
Post the rs6000 builtins rewrite, some of the leftover builtin
code is redundant and can be removed.
This replaces the usage of bu_mask in rs6000_target_modify_macros
with checks against the rs6000_isa_flags equivalent direc
On Thu, 2022-07-14 at 11:28 +0800, Kewen.Lin wrote:
> Hi Will,
>
> Thanks for the cleanup! Some comments are inlined.
Hi,
Thanks for the review. A few comments and responses below. TLDR I'll
incorporate the suggestions in V2 that will show up ... after. :-)
>
> on 2
[PATCH, rs6000] Additional cleanup of rs6000_builtin_mask
Hi,
Post the rs6000 builtins rewrite, some of the leftover builtin
code is redundant and can be removed.
This replaces the remaining usage of bu_mask in
rs6000_target_modify_macros() with checks against the rs6000_cpu directly.
Thus
On Wed, 2022-07-13 at 14:39 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Jul 13, 2022 at 01:18:29PM -0500, will schmidt wrote:
> > This cleans up some of the naming around the vstrir and vstril
> > instruction definitions, with some cosmetic changes for
>
[PATCH, rs6000] Cleanup some vstrir define_expand naming inconsistencies
Hi,
This cleans up some of the naming around the vstrir and vstril
instruction definitions, with some cosmetic changes for consistency.
No functional changes.
Regtested just in case, no regressions. :-)
OK for trunk?
Than
On Tue, 2022-06-07 at 23:16 -0400, Michael Meissner wrote:
> On Tue, Jun 07, 2022 at 07:59:34PM -0500, Peter Bergner wrote:
> > On 6/7/22 4:24 PM, Segher Boessenkool wrote:
> > > On Tue, Jun 07, 2022 at 04:17:04PM -0500, Peter Bergner wrote:
> > > > I think I mentioned this offline, but I'd prefer
On Tue, 2022-06-07 at 15:21 -0500, Segher Boessenkool wrote:
> On Tue, Jun 07, 2022 at 02:26:17PM -0500, will schmidt wrote:
> > On Mon, 2022-06-06 at 20:31 -0400, Michael Meissner wrote:
> > > (define_insn "vsx_xxspltd_"
> > >[(set (match_operan
On Mon, 2022-06-06 at 20:56 -0400, Michael Meissner wrote:
> [PATCH 3/3] Adjust MMA tests to account for no store vector pair.
>
> In changing the default for generating the store vector pair instructions,
> I had to adjust several of the MMA tests to remove checking for these
> instructions. Mos
On Mon, 2022-06-06 at 20:55 -0400, Michael Meissner wrote:
> [PATCH 1/3] Disable generating store vector pair.
>
> Testing has revealed that the power10 has some slowdowns if the store
> vector pair instruction is generated in some cases. This patch disables
> generating the store vector pair ins
On Mon, 2022-06-06 at 20:55 -0400, Michael Meissner wrote:
> [PATCH 2/3] Disable generating load/store vector pairs for block copies.
>
> If the store vector pair instruction is disabled, do not generate block
> copies that use load and store vector pair instructions.
>
> I have built bootstrap c
On Mon, 2022-06-06 at 20:31 -0400, Michael Meissner wrote:
> Optimize vec_splats of constant vec_extract for V2DI/V2DF, PR target
> 99293.
>
> This is version 3 of the patch. The original patch was:
>
> > Date: Mon, 28 Mar 2022 12:26:02 -0400
> > Subject: [PATCH 1/4] Optimize vec_splats of const
7;s ...
Additional comments below.
I've made note of the comments, and request (ask) that this be
approved, with a pinky promise that I intend to follow up on the
suggestions in my next patch series.
>
> on 2022/6/7 06:05, will schmidt wrote:
> > [PATCH,RS6000 2/5) Rework the
[PATCH,RS6000 4/5] Replace MASK_ with OPTION_MASK_
This replaces the MASK_ references with OPTION_MASK_
and removes the now unused defines.
This patch removes the defines for
MASK_ALTIVEC, MASK_CMPB, MASK_CRYPTO, MASK_DFP,
MASK_DIRECT_MOVE, MASK_DLMZB, MASK_EABI, MASK_FLOAT128_KEYWORD,
MASK_FLOAT
[PATCH,RS6000 5/5] Replace MASK_ usage with OPTION_MASK_
This continues the changes of replacing the MASK_ defines
with their OPTION_MASK_ equivalents.
This patch removes the defines for
MASK_P8_VECTOR, MASK_P9_VECTOR, MASK_P9_MISC, MASK_POPCNTB,
MASK_POPCNTD, MASK_PPC_GFXOPT, MASK_PPC_GPOPT, MAS
[PATCH, RS6000 3/5] Rework the RS6000_BTM defines, continued.
The RS6000_BTM_ definitions are mostly unused after
the rs6000 builtin code was reworked. This cleans
up the remaining RS6000_BTM_ references by replacing
them with their OPTION_MASK_ equivalents.
This patch removes the defines
RS600
[PATCH,RS6000 2/5) Rework the RS6000_BTM defines.
The RS6000_BTM_ definitions are mostly unused after the rs6000
builtin code was reworked. The remaining references can be replaced
with the OPTION_MASK_ and MASK_ equivalents.
This patch remvoes the defines:
RS6000_BTM_FRES, RS6000_BTM_FRSQRTE, R
[PATCH,RS6000 1/5] Clean-up MASK_ and RS6000_BTM_ definitions.
Hi,
This patch removes the defines that are no longer used, and
updates the comment for the set of MASK_ defines.
This patch removes the defines for
MASK_REGNAMES, MASK_PROTOTYPE, RS6000_BTM_ALWAYS, RS6000_BTM_COMMON.
gcc/
*
Hi,
This series cleans up the assorted MASK_, OPTION_MASK_,
and RS6000_BTM_ defines that we have sprinkled through the
rs6000 target code.
The MASK_ entries are currently defined as their OPTION_MASK_
equivalents since their introduction when the rs6000_isa_flags was
added via commit 4d9675496a2
On Thu, 2022-05-26 at 13:31 -0500, Segher Boessenkool wrote:
> > >
> On Thu, May 26, 2022 at 09:40:18AM -0500, will schmidt wrote:
> > On Thu, 2022-05-26 at 05:47 -0500, Segher Boessenkool wrote:
>
> > I'll dig a bit more, but would handle that in a separat
On Thu, 2022-05-26 at 05:47 -0500, Segher Boessenkool wrote:
> Hi!
>
Hi,
Thanks Kewen and Segher for the reviews. Additional comments below.
> On Thu, May 26, 2022 at 03:01:37PM +0800, Kewen.Lin wrote:
> > on 2022/5/26 14:12, Kewen.Lin via Gcc-patches wrote:
> > >
[PATCH, rs6000] Clean up the option_mask defines (part 3)
Hi,
Per code review, the MASK_REGNAMES, OPTION_MASK_REGNAMES,
MASK_PROTOTYPE, OPTION_MASK_PROTOTYPE options are not used
elsewhere in the codebase. Thus it should be safe to remove them.
This includes an update to a nearby comment to hin
[PATCH, rs6000] Clean up the option_mask defines (part 2)
Hi,
This patch reworks most of the lingering MASK_*
values to OPTION_MASK_* and removes the now redundant defines.
Regtested OK on power10. OK for trunk?
gcc/
* rs6000.h (RS6000_BTM_VSX, RS6000_BTM_P8_VECTOR, RS6000_BTM_P9_VE
[PATCH, rs6000] Clean up the option_mask defines
Hi,
We have an assortment of MASK and OPTION_MASK #defines throughout
the rs6000 code, MASK_ALTIVEC and OPTION_MASK_ALTIVEC as an example.
We currently #define the MASK_ entries to their OPTION_MASK_
equivalents so the two names could be used
On Tue, 2022-05-17 at 23:15 -0400, Michael Meissner wrote:
> On Fri, May 13, 2022 at 01:20:30PM -0500, will schmidt wrote:
> > On Fri, 2022-05-13 at 12:17 -0400, Michael Meissner wrote:
> > >
> > >
> > > gcc/
> > > PR target/103109
> >
I have updated
the comment to refer to "SPECIAL" processing, instead of having it
refer directly to the RS6000_BTC_SPECIAL macro.
2022-05-17 Will Schmidt
gcc/
* config/rs6000/rs6000-builtins.def: rephrase
RS6000_BTC_SPECIAL in comment.
* config/rs6000/rs6000.
On Fri, 2022-05-13 at 12:19 -0400, Michael Meissner wrote:
> Generate vadduqm and vsubuqm for TImode add/subtract
>
> If the TImode variable is in an Altivec register instead of a GPR
> register, then generate vadduqm and vsubuqm instead of having to move the
> value to the GPR registers and doing
On Fri, 2022-05-13 at 12:17 -0400, Michael Meissner wrote:
> Optimize multiply/add of DImode extended to TImode, PR target/103109.
>
> On power9 and power10 systems, we have instructions that support doing
> 64-bit integers converted to 128-bit integers and producing 128-bit
> results. This patch
On Fri, 2022-05-13 at 12:13 -0400, Michael Meissner wrote:
> Add zero_extendditi2. Improve lxvr*x code generation.
>
Content here matches what I commented on in the prior email with
subject "Delay splitting addti3...".
> This pattern adds zero_extendditi2 so that if we are extending DIm
On Fri, 2022-05-13 at 11:08 -0400, Michael Meissner wrote:
> Add zero_extendditi2. Improve lxvr*x code generation.
>
Hi,
> Subject: Re: [PATCH] Delay splitting addti3/subti3 until first split
pass.
Subject does not seem to match contents?
> This pattern adds zero_extendditi2 so that if w
On Fri, 2022-05-13 at 10:52 -0400, Michael Meissner wrote:
> Replace UNSPEC with RTL code for extendditi2.
>
Hi,
> When I submitted my patch on March 12th for extendditi2, Segher
> wished I
> had removed the use of the UNSPEC for the vextsd2q instruction. This
> patch rewrites extendditi2_vect
On Fri, 2022-05-13 at 10:49 -0400, Michael Meissner wrote:
> Optimize vec_splats of constant V2DI/V2DF vec_extract, PR target/99293.
>
> This patch has been previously posted, but it seemed to get lost.:
>
> > Date: Tue, 29 Mar 2022 23:25:31 -0400
> > Subject: [PATCH, V2] Optimize vec_splats of c
On Tue, 2022-04-12 at 21:14 -0400, Michael Meissner wrote:
> Eliminate power8 fusion options, use power8 tuning, PR target/102059
>
> This is V4 of the patch. Compared to V3 of the patch, GCC will just
> ignore -m{,no-}power8-fusion and -m{,no-}power8-fusion-sign.
>
Hi,
No comments on code, a
On Mon, 2022-02-28 at 11:17 +0800, HAO CHEN GUI via Gcc-patches wrote:
> Hi,
> This patch corrects the match pattern in pr56605.c. The former pattern
> is wrong and test case fails with GCC11. It should match following insn on
> each subtarget after mode promotion is disabled. The patch need to b
On Mon, 2022-02-28 at 13:37 +0800, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As PR103196 shows, p9-vec-length-full-7.c needs to be adjusted as the
> complete unrolling can happen on some of its loops. This patch is to
> use pragma "GCC unroll 0" to disable all possible loop unrollings.
> Hope it
On Thu, 2022-04-07 at 06:00 -0500, Segher Boessenkool wrote:
> On Thu, Apr 07, 2022 at 12:29:45AM -0400, Michael Meissner wrote:
> > In PR target/104253, it was pointed out the that test case added as part
> > of fixing the PR does not work on VxWorks because float128 is not
> > supported on that s
On Thu, 2022-04-07 at 17:29 +0800, Kewen.Lin wrote:
> Hi,
>
> As PR103353 shows, we may want to continue to expand a MMA built-in
> function like a normal function, even if we have already emitted
> error messages about some missing required conditions. As shown in
> that PR, without one explicit
On Wed, 2022-04-06 at 14:21 -0400, Michael Meissner wrote:
> From bf51c49f1481001c7b3223474d261dcbf9365eda Mon Sep 17 00:00:00 2001
> From: Michael Meissner
> Date: Fri, 1 Apr 2022 22:27:13 -0400
> Subject: [PATCH] Add zero_extendditi2. Improve lxvr*x code generation.
>
Hi,
> This pattern adds
On Thu, 2022-03-03 at 16:38 +0800, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
Hi
> As PR103353 shows, we may want to continue to expand a MMA built-in
> function like a normal function, even if we have already emitted
> error messages about some missing required conditions. As shown in
> that PR,
On Fri, 2022-01-28 at 11:50 -0600, Bill Schmidt via Gcc-patches wrote:
> PR104004 caught some misses on my part in converting to the new
> built-in
> function infrastructure. In particular, I forgot to mark all of the
> "nosoft"
> built-ins, and one of those should also have been marked "no32bit".
On Mon, 2022-03-21 at 09:51 +0800, HAO CHEN GUI wrote:
> Hi,
>This patch adds V1TI mode into a new mode iterator used in vector
> comparison expands.Without the patch, the comparisons between two vector
> __int128 are converted to scalar comparisons with branches. The code is
> suboptimal.The p
On Thu, 2022-03-17 at 13:35 +0800, HAO CHEN GUI via Gcc-patches wrote:
> Hi,
>This patch adds V1TI mode into a new mode iterator used in vector
> comparison expands.With the patch, both built-ins and direct
> comparison
> could generate P10 new V1TI comparison instructions.
Hi,
-/* We de
On Wed, 2022-03-16 at 13:12 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Mar 16, 2022 at 12:20:18PM -0500, will schmidt wrote:
> > For PR100693, we currently provide an addg6s builtin using unsigned
> > int arguments, but we are missing an unsigned long long argument
power8,power9,power10.
2022-03-15 Will Schmidt
gcc/
PR target/100693
* config/rs6000/rs600-builtins.def: Remove entry for __builtin_addgs()
and add entries for __builtin_addg6s_di() and __builtin_addg6s_si().
* config/rs6000/rs6000-overload.def: Add overloaded
On Thu, 2022-03-10 at 13:49 -0600, Segher Boessenkool wrote:
> On Thu, Mar 10, 2022 at 10:44:52AM -0600, will schmidt wrote:
> > On Wed, 2022-03-09 at 22:49 -0500, Michael Meissner wrote:
> > > --- a/gcc/config/rs6000/rs6000-cpus.def
> > > +++ b/gcc/config/rs6000/rs6
On Wed, 2022-03-09 at 22:49 -0500, Michael Meissner wrote:
> Eliminate power8 fusion options, use power8 tuning, PR target/102059
Hi,
>
> The power8 fusion support used to be set automatically when -mcpu=power8 or
> -mtune=power8 was used, and it was cleared for other cpu's. However, if you
> u
On Mon, 2022-02-28 at 22:21 -0500, Michael Meissner wrote:
> Optimize signed DImode -> TImode on power10, PR target/104698.
>
Hi,
Logic seems OK to me, a few suggestions on the comments intermixed
below. As always, i defer if there are counter arguments. :-)
> On power10, GCC tries to optimi
On Fri, 2021-11-05 at 00:11 -0400, Michael Meissner wrote:
> Generate XXSPLTIDP for scalars on power10.
>
> This patch implements XXSPLTIDP support for SF, and DF scalar constants.
> The previous patch added support for vector constants. This patch adds
> the support for SFmode and DFmode scalar
On Fri, 2021-11-05 at 00:10 -0400, Michael Meissner wrote:
> Generate XXSPLTIDP for vectors on power10.
>
> This patch implements XXSPLTIDP support for all vector constants. The
> XXSPLTIDP instruction is given a 32-bit immediate that is converted to a
> vector
> of two DFmode constants. The im
On Fri, 2021-11-05 at 00:09 -0400, Michael Meissner wrote:
> Generate XXSPLTIW on power10.
>
Hi,
> This patch adds support to automatically generate the ISA 3.1 XXSPLTIW
> instruction for V8HImode, V4SImode, and V4SFmode vectors. It does this by
> adding support for vector constants that can b
On Fri, 2021-11-05 at 00:07 -0400, Michael Meissner wrote:
> Add LXVKQ support.
>
> This patch adds support to generate the LXVKQ instruction to load specific
> IEEE-128 floating point constants.
>
> Compared to the last time I submitted this patch, I modified it so that it
> uses the bit pattern
On Fri, 2021-11-05 at 00:04 -0400, Michael Meissner wrote:
> Add new constant data structure.
>
> This patch provides the data structure and function to convert a
> CONST_INT, CONST_DOUBLE, CONST_VECTOR, or VEC_DUPLICATE of a constant) to
> an array of bytes, half-words, words, and double words t
On Mon, 2021-10-25 at 14:41 -0500, Pat Haugen via Gcc-patches wrote:
> Ping.
>
> On 8/10/21 10:49 AM, Pat Haugen via Gcc-patches wrote:
> > On 7/27/21 1:35 PM, will schmidt wrote:
> > > On Fri, 2021-07-23 at 15:23 -0500, Pat Haugen via Gcc-patches wrote:
> > > &g
On Tue, 2021-09-21 at 17:35 -0500, Bill Schmidt wrote:
> Hi!
>
> Previously zero-width bit fields were removed from structs, so that otherwise
> homogeneous aggregates were treated as such and passed in FPRs and VSRs.
> This was incorrect behavior per the ELFv2 ABI. Now that these fields are no
>
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
> This patch just duplicates a couple of functions and adjusts them to use the
> new builtin names. There's no logical change otherwise.
>
> 2021-08-31 Bill Schmidt
>
> gcc/
> * config/rs6000/rs6000.c (rs6000-builtin
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
> Peter Bergner recently added two new builtins __builtin_vsx_lxvp and
> __builtin_vsx_stxvp. These happened to break a pattern in MMA builtins that
> I had been using to automate gimple folding of MMA builtins. Previously,
>
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
> 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
> these f
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
> I over-restricted use of __builtin_mffsl, since I was unaware that it
> automatically uses mffs when mffsl is not available. Paul Clarke
> pointed
> this out in discussion of his SSE 4.1 compatibility patches.
>
> 2021-08-31
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
Hi,
Just a couple cosmetic nits noted below, the majority if which is also in
the original code this is based on.
THanks
-Will
> Although this patch looks quite large, the changes are fairly minimal.
> Most of it is dupl
On Wed, 2021-08-25 at 15:46 -0400, Michael Meissner wrote:
> Generate XXSPLTIDP on power10.
>
> This patch implements XXSPLTIDP support for SF and DF scalar constants and
> V2DF
> vector constants. The XXSPLTIDP instruction is given a 32-bit immediate that
> is converted to a vector of two DFmod
On Thu, 2021-07-29 at 08:30 -0500, Bill Schmidt wrote:
> 2021-04-02 Bill Schmidt
>
Hi,
> gcc/
> * config/rs6000/rs6000-builtin-new.def: Add power7 and power7-64
> stanzas.
ok
> ---
> gcc/config/rs6000/rs6000-builtin-new.def | 39
> 1 file changed, 39
On Thu, 2021-07-29 at 08:30 -0500, Bill Schmidt wrote:
> 2021-06-07 Bill Schmidt
>
> gcc/
> * config/rs6000/rs6000-builtin-new.def: Add always, power5, and
> power6 stanzas.
> ---
> gcc/config/rs6000/rs6000-builtin-new.def | 72
> 1 file changed, 72 inserti
On Thu, 2021-07-29 at 08:30 -0500, Bill Schmidt wrote:
> 2021-06-07 Bill Schmidt
>
Hi,
> gcc/
> * config/rs6000/rs6000-builtin-new.def: Add vsx stanza.
> ---
> gcc/config/rs6000/rs6000-builtin-new.def | 857 +++
> 1 file changed, 857 insertions(+)
>
ok
> diff -
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 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:
> 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 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
>
> 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-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-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-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-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-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-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-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-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 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: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 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 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 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 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: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:47 -0400, Michael Meissner wrote:
> [PATCH 2/2] Fix xxeval predicates.
>
> In doing the patch to move the XX* built-in functions from altivec.md to
> vsx.md, I noticed that the xxeval built-in function used the
> altivec_register_operand predicate. Since it takes vsx regi
On Tue, 2021-05-18 at 16:46 -0400, Michael Meissner wrote:
> [PATCH 1/2] Move xx* builtins to vsx.md.
>
Hi,
> I noticed that the xx built-in functions (xxspltiw, xxspltidp, xxsplti32dx,
> xxeval, xxblend, and xxpermx) were all defined in altivec.md. However, since
> the XX instructions can tak
On Tue, 2021-05-18 at 16:39 -0400, Michael Meissner wrote:
> [PATCH] Change rs6000_const_f32_to_i32 return type.
>
> The function rs6000_const_f32_to_i32 called REAL_VALUE_TO_TARGET_SINGLE
> with a long long type and returns it. This patch changes the type to long
> which is the proper type for R
On Tue, 2021-05-18 at 16:36 -0400, Michael Meissner wrote:
> [PATCH] Allow __ibm128 on older PowerPC systems.
>
Hi,
> On January 8th, 2018, I added code to ibm-ldouble.c to use the built-in
> function __builtin_pack_ibm128 if long double is IEEE 128-bit and continue to
> use __builtin_pack_long
On Tue, 2021-05-18 at 16:32 -0400, Michael Meissner wrote:
> [PATCH] Fix long double tests when default long double is not IBM.
>
Hi,
> This patch adds 3 more selections to target-supports.exp to see if we can
> force
> the compiler to use a particular long double format (IEEE 128-bit, IBM
>
On Tue, 2021-05-18 at 16:28 -0400, Michael Meissner wrote:
> [PATCH 2/2] Add IEEE 128-bit fp conditional move on PowerPC.
>
Hi,
> This patch adds the support for power10 IEEE 128-bit floating point
> conditional
> move and for automatically generating min/max.
>
> In this patch, I simplified
On Tue, 2021-05-18 at 16:26 -0400, Michael Meissner wrote:
> [PATCH 1/2] Add IEEE 128-bit min/max support on PowerPC.
>
Hi,
> This patch adds the support for the IEEE 128-bit floating point C minimum and
> maximum instructions. The next patch will add the support for using the
> compare and se
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
1 - 100 of 469 matches
Mail list logo
